Allow for multiple overridden types at once

[CarstenWickner]

There is already a way to override a given property's type by way of:

• SchemaGeneratorConfigPart.withTargetTypeOverrideResolver()

However, that only allows for one-to-one replacements -- e.g. replacing all occurrences of an interface with a single implementation that may contain more/different properties.

But what about those cases, where an interface is implemented by multiple types -- e.g. a Pet being either a Cat or a Dog?

The generator (and its configuration) should therefore be extended to:

1. allow for (multiple) subtypes to be identified,
2. in case of multiple of those subtypes, they should be included separately via anyOf (since oneOf would require them to be mutually exclusive).

[CarstenWickner]

PR #35 introduces the subtype resolution in general – including identified/applicable ones in an "anyOf" block with (for now) one known limitation:

• Additional type parameters on subtypes that have no relation to type parameters on the supertype result in an IllegalArgumentException being thrown when calling TypeContext.resolveSubtype(ResolvedType, Class<?>) (refer to Allow for subtype resolution with unknown generics FasterXML/java-classmate#53 for details)

For non-generic subtypes, this should be good to go.

[CarstenWickner]

The above has been released in v4.4.0.

[JanLabrie]

I experienced a problem trying to implement the
@JsonTypeInfo(include = JsonTypeInfo.As.WRAPPER_OBJECT) strategy.
Details are in the attached document:
SchemaGenerationIssueDetails.pdf

[CarstenWickner]

The reason for the infinite loop is, that the createStandardDefinition() method assumes that you will change the returned definition afterwards and therefore excludes it from the "definitions" stack, which are only visited once.

In your given example, you don't change the returned standard definition but rather want to simply include it and by-pass your own CustomDefinitionProvider. I hadn't considered that before until I encountered the same infinite loop. Therefore, in the linked pull request #35 I introduced a new createStandardDefinitionReference() method for when you do not intend to change that returned definition.

Using createStandardDefinitionReference() should avoid the infinite loop. 😄