Upgrades swagger parser to 2.1.1, allows ingestion of 3.1.0 specs

Created by: spacether

• updates swagger parser to 2.1.1 (not 2.1.2 because it omits processing of component vendor extensions which the 3_0_3 spec client tests need)
• when a spec version is >= 3.1.0 a warning is logged mentioning that 3.1.0 features are being added and that it is not fully supported yet
• adds test that checks that assigning a 3.1.0 spec works

After this PR is merged, developers will be able to start building and and testing 3.1.0 features into generators.

Research done on using the inferSchemaType parse option flag

When using setInferSchemaType(false) or setDefaultSchemaTypeObject(false)

swagger-parser: v2.1.2

• Parser works, but incorrectly reports errors per https://github.com/swagger-api/swagger-parser/issues/1792
• I targeted this version so I could include this setInferSchemaType(false) fix: https://github.com/swagger-api/swagger-parser/pull/1768
• To use this version of the parser with this option on, we would have to turn spec validation off for all generation which we should probably not

swagger-parser: v2.1.1

• Parser works, but incorrectly reports errors per https://github.com/swagger-api/swagger-parser/issues/1792
• I targeted this version so I could include this setDefaultSchemaTypeObject(false) https://github.com/swagger-api/swagger-parser/commit/cd0e2a85575221f403e01ed90046864ebaeed3fd
• To use this version of the parser with this option on, we would have to turn spec validation off for all generation which we should probably not
• swagger-parser bug: additionalProperties information forgotten from AdditionalpropertiesAllowsASchemaWhichShouldValidate

swagger-parser: v2.1.0

• Parser works, but incorrectly reports errors per https://github.com/swagger-api/swagger-parser/issues/1792
• I targeted this version so I could include this setDefaultSchemaTypeObject(false) https://github.com/swagger-api/swagger-parser/commit/cd0e2a85575221f403e01ed90046864ebaeed3fd
• To use this version of the parser with this option on, we would have to turn spec validation off for all generation which we should probably not

When using setInferSchemaType(true) or setDefaultSchemaTypeObject(true)

swagger-parser: v2.1.0

• Parser works, no errors reported
• 72 files changed mainly example: null additions to spec yaml files

swagger-parser: v2.1.1

• Parser works, no errors reported
• same 72 files changed mainly example: null additions to spec yaml files

swagger-parser: v2.1.2

• parser works, errors reported during sample generation

	-paths.'/pet'(post).parameters.[header1].schemas.$ref target #/components/requestBodies/Pet is not of expected type Schema
	-paths.'/pet'(post).parameters.[header2].schemas.$ref target #/components/requestBodies/Pet is not of expected type Schema

• these errors are correct and come from modules/openapi-generator/src/test/resources/3_0/petstore-with-complex-headers.yaml
• 513 files changed, mainly type: object additions + python experimental unit test spec model and endpoint test file deletions. Excluding the python changes 88 files are impacted. (why did the python tests get deleted?)
• probably the extension data stopped being processed correctly?

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh

  Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (6.1.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.