[core] Validation properties standardization

This should address #4653 (closed)

The request was to add validation properties to CodegenModel, where CodegenModel may be used to represent reusable schemas which don't necessary result in a generated model (see isString, isInteger, etc). Those use cases are legacy functionality from before there was a standardized structure in swagger-parser (now, Schema). I couldn't find any usages in template code, but that's not to say that users with customized templates aren't relying heavily on CodegenModel and legacy functionality. I've added the set of validation properties to CodegenModel to address this issue, but I think we should work out a deprecation strategy if CodegenModel is no longer meant to be used for primitive schemas. That is, an OpenAPI Schema representing a primitive type should never be a model in generated code.

The heart of the discussion in the linked issue is this:

• CodegenModel appears to be considered the "most proper" transformation from Schema to some type within OpenAPI Generator
• The ask is to not drop JSON Schema Validation Properties whenever we convert from a Schema instance to one of the Codegen* types in OpenAPI Generator
• The use case this would allow is model reuse in generated code which requires pre-condition and post-condition checks.

This PR will address issues in our other Codegen* types, such as the copy method on CodegenParameter would previously not copy pattern, minimum or maximum. CodegenResponse previously had not validation properties. The previous assumption seems to be that CodegenResponse, for instance, didn't require validation; that's not really the case in microservices, and especially not in OLTP where data consistency is key and something like pattern or length checks could prevent security breaches.

I'm opening this for feedback. If reviewers feel that CodegenModel does not require these validation properties, I'd prefer to remove them from that class.

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

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.