consider type naming

JSON schema gives us two direct sources of types names: the keys in references dictionary and the title field in schema metadata. Note also that while the former are necessarily unique, the latter may not be. In addition, we can get hints about names. Consider for example a JSON object that looks like this:

{
    "fooObj": {
        "a": 7,
        "b": 8
    }
}

The outer object may have a name, but the value of fooObj may not (or it may have a title that is not unique). We could include a "distinguishing hint" in these cases which might be the enclosing type and property name, or may come from the external caller e.g. our OpenAPI processor could use the operationId.

After processing all types, we could choose to always include the distinguishing hint in the name, only include it if it was needed to resolve conflicting types, or raise an error if it as needed to disambiguate conflicting types.

This would require a change in the API which currently is of the form schemars::schema::Schema -> proc_macro2::TokenStream i.e. we will no longer be sure of the type name until all schemas have been examined.

Start by tracing the current schemars::schema::Schema to proc_macro2::TokenStream API and how all schemas are processed. Review the naming sources described in the issue, including references keys, schema title, enclosing property names, and OpenAPI operationId hints. Done requires a decided disambiguation policy and an API that can defer type naming until schemas have been examined.