Rewrite the Hyper-Schema spec almost entirely

This more or less includes all open PRs, including the one for
moving the applicability concept over to the validation spec.

This is a ROUGH DRAFT.  The goals are:

* Is this the right scope?  Or should things go on the web site?
* Are these the right sections, in the right order?
* Can you more or less get the point of each paragraph?

The following feedback is NOT WANTED at this time:

* spelling and grammar
* consistency of wording (unless it's incomprehensible)
* commentary on how sentences flow (unless it's incomprehensible)
* complaints about the temporary lack of examples
* commentary about missing or inconsistent xrefs

I ripped out all of the examples because it made it about 5000%
easier for me to work with the document, and we know we want
to write them anyway.  Keep a copy of the version from master
around if you want to reference the existing examples while
reviewing this new draft.

-----

DON'T FORGET TO READ THE CREFs!

There are several places where I opted to write a cref note
instead of continuing to try to hammer out the proper text.

-----

Here are the main changes, aside from those that have also been
submitted as separate PRs:

* Set context in the overview and explain purpose.  This should
  probably be trimmed back down some.

* Start with a general, high-level definition of what it means
  to implement hyper-schema.  This provides a framework for
  understanding the individual keywords.

* Due to high-level requirements up front, and details of the
  whole URI Template resolution process, HTTP usage, security
  concerns, and API usage factored out to their own sections
  or appendices, the individual keyword sections focus on the
  key basic definitions

* Schema keywords discussed in terms of applicability.  Clarified
  requirements on how to handle "base".

* LDO keywords restructured around the abstract link model
   * Context identification keywords first
   * Link relations next
   * Target identification rounds out the required concepts
   * Template process keywords, which apply to context and target
   * Target attributes (emphasize advisory nature in intro paragraph)
   * Input keywords, grouped by usage

* URI Template resolution process factored out to its own section,
  with pseudocode.  Probably needs more explanatory text.

* Security Considerations section instead of interrupting the flow
  of keywords as they are defined.

* Consolidated HTTP usage notes into an appendix.  This thoroughly
  covers how to use JSON Hyper-Schema with HTTP.

* Added an appendix on how to use hyper-schema in APIs.  This is
  probably the most likely to move out to the web site.  I also
  was going to write more with analogies between API user agents
  and web browsers, but that got kind of bogged down so I stopped
  where it is now.

* Added an appending on static analysis of hyper-schemas.  This is
  where a lot of usage goes wrong in terms of expectations, so
  briefly addressing it in the spec seems wise.

I'm probably missing something, but I'm pretty sure those are
all of the really big things.

Author: handrews

hyper-schema.json

@@ -50,7 +50,8 @@
         "propertyNames": { "$ref": "#" },
 
         "base": {
-            "type": "string"
+            "type": "string",
+            "format": "uri-template"
         },
         "links": {
             "type": "array",