[python-experimental] adds dict["key_name"] type hints

Created by: spacether

• Uses frozendict module import in all locations
• Fixed bug where DictSchemas were not inheriting from frozendict in pycharm
• adds dict["key_name"] hints
• handles case where additionalProperties is None, last get_items must not be overload and should be last optional parameter.
• .pyi stub files added for models and endpoints so pycharm can read get_item overloads

.pyi Stub Files added

They were added to allow pycharm can read get_item overloads They needed to be added because there is a bug in pycharm where it can only read overloads in stub files. Once https://youtrack.jetbrains.com/issue/PY-42137/PyCharm-type-hinting-doesnt-work-well-with-overload-decorator is fixed, they can be removed.

Notes

The properties locals()[propName] = method_name feature has been removed because I could not use it to set type hints for (python) invalidly named properties. So instead, a valid python name is used for the property, and the properties.__attributes__ dict stores the map from propertyName to schema definition.

In pycharm some_dict["someProp"] types are (incorrectly per openapi) reported as a union of the actual type and the additionalProperties type because all of the string literals are also of type string. One could get this to work by manually passing in a boolean is_additional_property as a second argument to select the correct method signature. BUT pycharm cannot see that "prop" in Model.MetaOapg.properties.__annotations__ is True so even then the user will have to manually set is_additional_property to True or false to get an accurate type in pycharm for that use case.

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.