Proposal: Subschema iteration/recursion

[handrews]

@marksparkza thanks for renaming the Applicator hierarchy! I had been putting off filing an issue for that because I also wanted to propose the changes I'm suggesting here (and thought I'd get around to filing this more quickly).

I've implemented draft-next's propertyDependencies, which is an object of objects of schemas, instead of the usual object of schemas (e.g. properties, patternProperties). Supporting this keyword required changes in three places, one of them relatively challenging:

• Piping a grandchild (or, more generally, descendant) constructor(s) through JSON so that the recursive instantiation would correctly create a JSONSchema two levels down
• Create a new ApplicatorMixin (SubschemaMixin) subclass for the two-level-down jsonify()
• Add a new clause to the conditionals in JSONSchema._resolve_references()

As you might expect, I did not figure all of these out at once 😅 I just kept failing tests and finding more spots to change. I posted part of the support as PR #63 but realized it was just hacking through part of a larger difficulty.

I think the preferable thing to do here would be to have the Subschema hierarchy support iterating over subschemas, both existing and to-be-instantiated. The thing that needs to be defined is the relationship structure of a keyword to its subschema(s). The current Subschema hierarchy does part of this with jsonify, but it could centralize the necessary logic for all of it.

The Subschema base class could implement resolve_references() as well as jsonify() using that information.

Another option would be for the Subschema base class to implement an iterator. If implemented as a generator that does a yield from each subschema's own subschema iteration, this could be a depth-first iterator supporting a Visitor pattern. Which could be used to implement resolve_references() and anything else similar. To make implementing this Visitor support simpler, the Keyword base class would want to implement the iterator and just immediately yield StopIteration.

Either way, the only information that's really needed is how many levels down the subschemas appear.

[handrews]

Having poked at this a bit because something like it will be needed to fix #88, I'm leaning towards a simpler iteration of immediate subschemas rather than an automatic depth-first full traversal. If something needs the depth-first traversal it can be added on top of that.

Also, while it would be possible to automate things from just the number of levels down the subschemas appear, that's also more ambitious than is immediately needed.