[BUG] anyOf not properly translating python unions

Description

The Python client typing for anyOf if not properly generating python Unions when there are two or more (non-None) types in the anyOf

openapi-generator version

openapi-generator-cli version 7.14.0

OpenAPI declaration file content or url

Original Python Code used to generate the OpenAPI spec

class TestModel(BaseModel):
    three_types: int | str | bool
    two_types_plus_none: str | int | None
    two_types: int | str
    one_type_plus_none: int | None

OpenAPI Model

Full Model is in the Gist
https://gist.github.com/jprince14/fd0f215c78a4a387762df9617f1f4b80

Snippet of the model

"TestModel": {
    "properties": {
        "three_types": {
            "anyOf": [
                {
                    "type": "integer"
                },
                {
                    "type": "string"
                },
                {
                    "type": "boolean"
                }
            ],

Python model generated by openapi-generator-cli

Python Client Gist
https://gist.github.com/jprince14/ca6fb39a6133b5fc96683dbffc70f22e

Snippet of generated python client

class TestModel(BaseModel):
    """
    TestModel
    """ # noqa: E501
    three_types: ThreeTypes
    two_types_plus_none: Optional[TwoTypesPlusNone]
    two_types: TwoTypes
    one_type_plus_none: Optional[StrictInt]

Generation Details

openapi-generator-cli generate -i openapi.json -g python

Steps to reproduce

Generate the python client

Related issues/PRs

I didn't see anything

Suggest a fix

Using three_types as an example, if the OpenAPI json is an anyOf(integer OR string OR boolean) why not make the python client type str|int|bool. Creating a pydantic model for three_types does not seem optimal

Reproduce the issue with the supplied OpenAPI model and openapi-generator-cli generate -i openapi.json -g python. Compare the generated TestModel in the linked Python client Gist with the expected union types for three_types, two_types_plus_none, and two_types; done means non-None anyOf variants are represented as Python unions rather than generated wrapper models.