Refactor to better mirror OpenAPI terminology

[dbanty]

Is your feature request related to a problem? Please describe.
Currently some of the terms / organization in this project don't line up very well with OpenAPI terminology.

Examples:

1. "Schema" in this project refers only to something declared in the "schemas" section of the OpenAPI document. In reality, the things we call "Response" and "Property" are also schemas in OpenAPI.
2. "Property" refers to some property within an including schema. Properties are themselves schemas, so should be named as such.
3. "Responses", rather than containing a schema, currently duplicate some of the behavior of schemas. This should be fixed.

Describe the solution you'd like
The best course of action, I think, is to separate the parsing of the OpenAPI document from the reorganization of data for client generation. Currently this is done all in one pass, mixing the logic and verbiage of the parsing with the client generation.

It may be possible to find a library which already exists which will parse the document into strongly typed objects. If not, I'll write one. The terminology of the parsed document should mirror the OpenAPI specification as closely as possible.

This project will then reorganize that already-parsed data into something that makes sense for client generation. Hopefully in the process some of the schema-logic can be simplified to make more interesting response types possible.

[dbanty]

I found https://github.com/kuimono/openapi-schema-pydantic which is pretty much perfect for our needs as a parser. I opened kuimono/openapi-schema-pydantic#1 to get a marker file so mypy will work with it. For now, going to use my fork from this project so we can get migrating.