Implement OAS 3.0 JSON Schema dialect in jschon

[handrews]

Since we're using jschon for schema validation in general, we'll use it to validate examples and defaults against their schemas. This means that we need support for the OAS 3.0 dialect. While jschon only supports drafts 2019-09 and above, we can implement the 3.0 dialect by:

• leveraging the 2020-12 core vocabulary but forbidding the use of its keywords with the dialect metaschema
• creating a draft-04 subset vocabulary consisting of the equivalent 2020-12 keywords except for exclusiveMinimum and exclusiveMaximum, which will need replacement implementations. Everything else (including items) that is supported in the OAS 3.0 Schema Object behaves the same (although see below on format)
• creating an OAS 3.0 extension vocabulary with the 2020-12 readOnly, writeOnly, and deprecated, and with custom implementations of nullable (the only assertion), discriminator, example, xml, and externalDocs (all annotations- at the moment it does not seem worth it to try to use discriminator to shortcut evaluation as it complicates annotation usage)
• enabling format validation in the jschon catalog and implementing the various formats, at least the ones in the spec and as many of the ones in the registry as is feasible (others may get added later).

[handrews]

Implemented in PR #16. There are more formats to add, but there are always more formats to add...

[MikeRalphson]

With respect to items did you mean the constraint that type: array MUST have a sibling items keyword in OAS 3.0.x, even if it is items: {} or items: true ?

[handrews]

@MikeRalphson I was not aware of such a constraint in OAS 3.0, but... 👀 huh, there it is. I can add that. I think that it will be a rule that needs to be turn-off-able, not unlike some format validation (e.g. GitHub's API description has a rather loose interpretation of "format": "uri" and fails validation because of it). But it's a MUST in the spec so it will need to be on by default.

I might implement that (and the next-to-allOf/anyOf/oneOf constraint for discriminator) with schema validation as otherwise I can't re-use the existing 2020-12 items implementation.

My comment on items was just about forbidding the array form of the keyword, which was split out into prefixItems in 2020-12.

Anyway, nice catch, feel free to file issues on anything that seems missing.