[Python] handle oneOf/allOf/anyOf composed schemas in the Python client

Created by: rienafairefr

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh, ./bin/security/{LANG}-petstore.sh and ./bin/openapi3/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language. @wing328 @ci

Description of the PR

I saw that allOf/oneOf/anyOf was not yet fully handled in general, and in particular for my use case, in the Python client codegen. This PR is a tentative to handle deserialization of models that use oneOf/anyOf/allOf, by making use of the allOf/oneOf/anyOf fields in CodegenModel

I've added a composed_hierarchy to the model, which is specified when the underlying openapi model uses oneOf/allOf/anyOf, if there is no discriminator field. When receiving some data, to deserialize it to the correct class, we try to match the incoming data to all possible subclasse

• oneOf: we raise an exception if 0 or more than one of them match
• allOf: we raise an exception if not all of them match
• anyOf: we raise an exception if 0 of them match

with oneOf/anyOf, the instance that is returned will be of the correct subclass, and with allOf, we return an instance of the current model class.

The case of a more advanced schema (when more than one of allOf/oneOf/anyOf is used) is not handled. Caveat: cases of inline models might not be handled properly in some or all of the cases.