fix getAllInvolvedRawTypes() recursing infinitely

[codecholeric]

This fixes the problem of recursing infinitely when calling JavaType.getAllInvolvedRawTypes()
for a recursive type parameter declaration (e.g. class Example<T extends Example<T>>).
It also adds a new public API to conveniently traverse JavaType signatures
without the need to add chains of instanceof checks and manually handle how to traverse further.

Resolves: #1237

[hankem]

LGTM! 👍

[hankem]

I wonder whether the default implementation should be

Suggested change

	return CONTINUE;
	return visitClass(type);

[codecholeric]

Hmm, but that would seem strange to me. Because the contract should be that visitClass is never called with an array type, right? (Otherwise, why even have visitClass and visitArrayType separately in the visitor? If you can't rely on isArray() to return false whenever visitClass is called?)
The traversal behavior will just traverse down to the component type by default, right? So implementing CONTINUE will finally call visitClass with the base component type, and that seems a reasonable behavior if I e.g. only implement visitClass but not visitArrayType 🤷

[hankem]

Because the contract should be that visitClass is never called with an array type, right?

Let's document the contract. 😉

I was checking whether we could make more use of the new SignatureVisitor internally, and found JavaClassDependencies.dependenciesOfType(JavaType). SignatureVisitor won't be a nice solution there, but I realized that there might be more use cases where one previously had

        if (javaType instanceof JavaClass) {
            // do something with `(JavaClass) javaType`
        } else if (javaType instanceof JavaParameterizedType) {
            // do something with `(JavaParameterizedType) javaType`
        } else if (javaType instanceof JavaWildcardType) {
            // do something with `(JavaWildcardType) javaType`
        }

and it might not immediately obvious that refactoring this to the SignatureVisitor pattern requires overwriting both visitClass and visitArrayType for the do something with `(JavaClass) javaType` part.

So yes, the question is actually whether SignatureVisitor should have individual methods for array and non-array JavaClasses. Having only one might be more consistent (why just distinguish arrays, and not, e.g. interfaces?) and therefore less confusing.

[codecholeric]

Hmm, I see your point, I just figured it would be kind of nice that the default behavior would traverse up the component types and automatically only give you the element type (as I found the JLS calls our "base component type" 🤪). But maybe that in the end creates a more confusing API instead of helping 🤔

[codecholeric]

One argument for the separate visitArrayType method might be that it's somewhat consistent with visitGenericArrayType 🤔 But I guess there the class hierarchy really is also distinct 🤷
Guess I'm gonna remove the array type method then...