Better Handling for "oneOf" (and "anyOf") Model Generation

Is your feature request related to a problem? Please describe.

The generated oneOf types in Java are often empty interfaces or classes with no properties and are not very useful.

Describe the solution you'd like

Change the model generation for oneOf (and anyOf) to rely on wrapper classes that JSON serialize and deserialize from their wrapped underlying values instead of using interfaces and
inheritance to try to represent disjoint classes (see README.md file in attached ZIP).

Describe alternatives you've considered

See the README.md file in the attached ZIP file as well as the example code. The basic usage of the generated wrapper classes would look like this:

    Name name = new Name();
    name.setGivenName("Joe");
    name.setSurname("Schmoe");

    NameRepresentation asName = NameRepresentation.from(name);

    NameRepresentation asString = NameRepresentation.from("Joe Schmoe");

    List<NameRepresentation> names = List.of(asName, asString);

    for (NameRepresentation nameRep : names) {
      if (nameRep.is(Name.class)) {
        Name value = nameRep.as(Name.class);
        System.out.println("Name is " + value.getGivenName()
                           + " " + value.getSurname());

      } else if (nameRep.is(String.class)) {
        String value = nameRep.as(String.class);
        System.out.println("Name is " + value);

      } else {
        throw new IllegalStateException(
          "Unhandled value type: " + nameRep.getValueType());
      }  
    }

Additional context

The attached file has a simple API server that implements a simple spec that uses oneOf with my model pattern. The README.md describes the usage and the details of the pattern. Additionally, you can actually run and test the server using the provided curl commands.
one-of-example.zip

Start with the attached README.md and one-of-example.zip to understand the proposed wrapper API, then locate the Java model-generation entry points for oneOf and anyOf. Use the example's curl commands to compare current behavior with the desired result; done means generated wrappers can serialize and deserialize their underlying values for both constructs.