ResolvedType.getAllTypes() returns parent, this, and interfaces

[krzysiekbielicki]

Convenience method for the full set of types for a type (fixes #50)

[cowtowncoder]

@krzysiekbielicki Thank you for contributing this! I hope to check out PR soon but have a few things queued up -- but I wanted to add a note to say that I saw this and will try to get to it ASAP.

@ljnelson WDYT?

[ljnelson]

I'll let you folks figure it out. I did my own thing over here. I opted to always include the full set of types, i.e. not just the parent but the grandparent and so on. See: https://microbean.github.io/microbean-type/apidocs/org/microbean/type/Types.html#toTypes(java.lang.reflect.Type)

[cowtowncoder]

Ah, right. So as implemented the method does not include types recursively, but only immediate parent. So yes, that should be added; at least I don't see as much value in something that only includes immediate super types.

[cowtowncoder]

Needs to resolve super types recursively, as methods called will only include immediate super class, interfaces implemented; but not super types of those types.

I think name should be getAllSuperTypes(); I also think that list should NOT include type itself (so that name makes sense in that context).
It might make sense to refactor this so that were two variants:

1. getAllSuperTypes() to work as described
2. addAllSuperTypes(Collection<ResolvedType>) that would add types into given set

... and come to think of this, I realized that List does not quite make sense here, for two reasons:

1. There is no well-defined ordering for inclusion; for this reason, we could just use Collection. But further,
2. Since it will be necessary to avoid duplicate interfaces (there are cases where things like java.io.Serializable are implemented via multiple super-interfaces).

So most likely return type really should be Set. This does open up some further questions (should differently parameterized super-types -- say, Comparable<X> vs Comparable<Y>; or, some cases, "raw" variant -- be included once or multiple times), but for now simple equality could work (which would lead to double inclusion for varying type parameters).

Finally, there may be a problem with recusive types (most common being Enum...), so a test for that might be needed. But I can take care of that.