Add an option to avoid the use of optional extras of Pydantic v2

[drsybren]

Is your feature request related to a problem? Please describe. I have a schema like this:

    Contact:
      type: object
      description: Owner / publisher of this asset library.
      properties:
        "name": { type: string }
        "url": { type: string, format: url }
        "email": { type: string, format: idn-email }
      required: [name, url, email]

This generates the attribute email: pydantic.EmailStr. However, pydantic.EmailStr is an optional extra in Pydantic, and is not available by default. It requires installing via pip install pydantic[email], which installs two extra packages (email_validator and dnspython). In my use case, I want to minimze the dependencies of the application, and would rather not use these validators. My use case also is only display of those email addresses; the application does not need to send any emails.

Describe the solution you'd like It would be great if we could get control over the use of optional Pydantic features. This could be as simple as:

# The current behaviour, which could remain the default:
$ datamodel-codegen --allow-pydantic-extras

# could be overriden with:
$ datamodel-codegen --disallow-pydantic-extras

Describe alternatives you've considered An alternative would be less Pydantic-specific, and give control over the validators (not) used. This could be by providing a set of type.format=package.class arguments. For example:

# The current behaviour, which would still remain the default:
$ datamodel-codegen --validator-map string.idn-email=pydantic.EmailStr

# could be overridden with:
$ datamodel-codegen --validator-map string.idn-email=str

Additional context

The alternative proposal might be more complex to use, but would give more power over what gets generated. Also it would be usable for other types as well, when the application doesn't care about exact validation. For example, in another project I have fields with { type: string; format: uuid } where the client application itself doesn't care whether it is a UUID or not. Having control here is nice.

My goal with datamodel-codegen is for integration with Blender, where we're looking at OpenAPI-based communication for a remote asset library system.

[trajano]

I wonder if the fix can be integrated with https://github.com/koxudaxi/datamodel-code-generator/issues/2368