support for setting/changing draft specification version from the "$schema" keyword

[karenetheridge]

The latest specification allows for $schema to appear anywhere a "schema resource" begins, which iff the "$id" keyword appears. In theory (even before supporting custom dialects) we should be able to switch between specification versions by encountering the "$schema" keyword whose value references one of the other draft specification URIs.

This is a necessary prerequisite for any sort of $vocabulary support (the document described by the URI needs to be loaded and parsed).

[karenetheridge]

This requires refactoring how we set up a schema document for traversal and evaluation -- we cannot instantiate vocabulary objects with $js->specification_version as today, as we will have already started traversal by the time we encounter the "$schema" keyword.

FOR NOW:

• $js->_traverse_subschema(), core vocabulary: consider the superset of keywords in the core vocabulary across all specification versions; every core keyword's traverse method needs to check the current specification version (in $state) to see if it is implemented in the current version (because that version can change in the middle of keyword traversal)
• when traversing the "$schema" keyword, determine the corresponding specification version and save in $state
• store vocabularies (or just the draft specification version) for this position in a cache on the document object, indexed by json pointer
• when evaluating, at each subschema (_eval_subschema), check document object's cache and set $state->{specification_version}.

LATER, when we support different dialects (and hence different vocabularies):

• $js->_traverse_subschema: start off with just the core vocabulary in a newly-instantiated dialect object (uri not yet set)
• when traversing the "$schema" keyword, determine the corresponding specification version and add on the remaining vocabularies for it to the dialect object (OR: if the URI is already in the cache, just use that)
• by the end of traversing core keywords, if no $schema keyword was encountered, add on the remaining vocabularies for the current specification version to the dialect object (OR just use the default dialect object for the default specification version - which should be in the cache)
• store the dialect object for this position in a cache on the document object, indexed by json pointer
• when evaluating, at each subschema (_eval_subschema), check document object's cache and set dialect object in $state.

[karenetheridge]

This is now done, as of release 0.518.