[core] cleanup: remove OpenAPI parameter from CodegenConfig methods

Created by: jmini

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 and ./bin/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. @OpenAPITools/generator-core-team

Description of the PR

In order to solve #1927 I will need to access the OpenAPI instance in DefaultCodegen#toDefaultValue(..) in order to be able to see if the schema contains a $ref and if this is the case, to see if the referenced schema has a default value or not.

The main change of this PR is to have:

• public String toDefaultValue(Schema p, OpenAPI openAPI)
• Instead of public String toDefaultValue(Schema p)

To fulfill this requirement the OpenAPI is added as parameter to some methods of DefaultCodegen.

Some of those methods also had Map<String, Schema> allDefinitions which corresponds to openAPI.getComponents().getSchemas(). This parameter was also removed from the methods, and the openAPI instance is used to access to all schemas.

Based on feedback the initial intention of this PR was changed.

Historically, to access the OpenAPI instance, or all schemas of the OpenAPI instance, parameters were used in different methods. Example:

• CodegenConfig#fromOperation(String, String, Operation, Map<String, Schema>, OpenAPI)
• CodegenConfig#fromModel(String, Schema, Map<String, Schema>)
• DefaultCodegen#fromResponse(OpenAPI, String, ApiResponse)
• DefaultCodegen#DefaultCodegen.fromRequestBody(RequestBody, Map<String, Schema>, Set<String>, String)
• DefaultCodegen#createDiscriminator(String, Schema, Map<String, Schema>)
• ...

Then @wing328 noticed that access to this information is requested in a lot of places (for unaliasing). So he introduced a new approach: having two members globalOpenAPI and globalSchemas.

Having two ways for doing the same task is not consistent. It is harder to understand, to maintain and can lead to errors (for example all the unit tests were not using globalOpenAPI, meaning that they were not reproducing real cases, because when the generator is used for real, then the globalOpenAPI member is set).

This PR cleans the situation by removing the original approach completely. There is no openAPI or allDefinitions parameter anymore in the methods. Instead they use the globalOpenAPI member which is renamed openAPI.

In addition globalSchemas was only a convenient and null-pointer safe access to openAPI.getComponents().getSchemas(). It is also removed.

This change is mentioned in the migration guide "From 3.x to 4.0.0"

In my opinion the PR improves the readability of the code and reduces the potential coding mistakes.