[bug][core] Copy all attributes (not properties) on composed schemas when flattening models

[jimschubert]

Fixes #6950

The model flattening for composed schemas was not copying all attributes of the schema being flattened. This broke inheritance across composed schemas, which is a feature that is supported by the specification.

cc @OpenAPITools/generator-core-team
cc @jeff9finger

Example output showing proper inheritance using spec from #6950:

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project beforehand.
• Run the shell script ./bin/generate-samples.shto update all Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[spacether]

So I have some questions about how our code works here. Can you help answer them?

1. This copies the property from the inline schema into the extracted schema that we put into openapi component schemas, right?
   So it sets the discriminator on this schema:

      - type: object
        discriminator: party_type
        required:
          - party_type
        properties:
          party_type:
            readOnly: true
            $ref: '#/definitions/PartyType'
          tax_id_number:
            type: string

Which is extracted and used to create the schema with the key Party_allOf, correct?
2. Is only one Party_allOf class made for each composed schema or is each inline schema extracted out into its own Party_allOf1, Party_allOf2 etc?
3. How about adding a javadoc to this method so one can understand this by reading the doc in the future?

[jimschubert]

Party_allOf will be created once, then any properties it references will be flattened. Later, we "lookup" the transient Party_allOf by serializing and deserializing the structure as the key of a map, and the value as a name. This is how we basically deduplicate those dynamic structures and associate them all with a generated name. See structureMapper in this PR which I've updated to have determinate property order. As it was, Jackson would probably serialize in the same way maybe 99% of the time, but without explicitly sorting it'll follow the same rules as JSON where map properties are technically unordered.

[jimschubert]

This PR adds to some work done in #6153, which caused master CircleCI to break due to two new properties in a test yaml file and type: object added to generated code for those properties.

These are fixed by this PR, so I'll go ahead and merge. If any reviewers have concerns we can address in a follow up change.