jschon and OpenAPI support (surprisingly simple... probably)

[handrews]

@marksparkza I'm using jschon in some contract work for OpenAPI / the Linux Foundation, and it turns out to be very difficult to work with a document that embeds JSON Schema in various locations, but is not overall a JSON Schema.

The issue is that the JSON/JSONSchema classes' mechanism (with SubschemaMixin.jsonify()) for choosing a subclass for list and dict values works one level at a time, and assumes that everything on the same level will use the same subclass (e.g. JSON vs JSONSchema).

My suggestion (and I'll post a PR since it's simple) is to make the list and dict instantiations methods that can be overridden in a subclass. An OAS-aware subclassof JSON can select the correct subclass (itself or JSONSchema) based on the position in the OAS document. Once a JSONSchema subclass is chosen, everything works normally as everything within an OAS Schema Object behaves like a schema keyword.

This is a very simple change that lets the OAS extension I'm working on hold the complexity, rather than trying to build support for arbitrarily complex JSON Schema-embedding formats into jschon itself. (There are other use cases for this, most notaby AsyncAPI which is still on draft-07, but also the W3C's Web of Things groups' Thing Description format - I believe they plan to update to 2020-12).

If possible, this and one other PR I am posting momentarily would make a very helpful 0.10.3 for me.

---

BTW, it was not hard to implement OAS 3.0's schema dialect in jschon even though it is draft-04 base, because it only uses keywords that have the same behavior in 2020-12; OAS 3.1's schema dialect is fully 2020-12 compatible, just with an extra vocabulary, so this project that I'm doing will end up providng OAS 3.x support for jschon if this issue is solved.

[handrews]

Doing this properly will require something much like #82 and its related PRs, and in OAS 3.1 #87. The subschema iteration idea in #77 would also help, as the notion of "subschema" gets interesting if you regard the entire OAS document as a kind of pseudo-JSON Schema.

@marksparkza this module has my (currently somewhat messy) work-in-progress on OAS support. I'll have to see if OAI/Linux Foundation would want to split that out to a separate installable module of just jschon OAS support later on.

[handrews]

An alternative approach to #101 could involve JSONSchema classes being aware that the root of the schema resource is not necessarily the document root. And knowing that other locations within the document are also schema resources and therefore valid $ref targets.

I'm not quite sure how that would work, but it would be different from what I'm doing with a #101-ish approach, where my JSON subclass tries to act enough like JSONSchema to be a functional schema root object, while not having to define an incredibly elaborate (and more problematically, context-sensitive) JSON Schema vocabulary for the entire OpenAPI structure.

This alternative might involve defining JSONSchema.parent and JSONSchema.root separately. Things like finding $id for a base URI would only walk up parent properties, but resolving a fragment-only reference would start from the root property. But there would still need to be a mechanism for indicating which locations need to be JSONSchema vs JSON (or some external-to-jschon subclass of JSON).

[handrews]

Closing in favor of the more general discussion #108