Refactoring for JSON API v1.0rc1

* New introduction explains the basics requirements and goals of JSON API. It
  also broadly explains the new optional PATCH support and how "JSON API
  represents all of a domain's resources as a single JSON document that can act
  as the target for operations".

* New "Conventions" section explains SHOULD, MUST, etc. keywords

* New "Document Structure" section describes the JSON API media type
  (application/vnd.api+json). This media type is used for both request and
  response documents (except for PATCH requests/responses).

* Introduces the option to key the primary resource by the generic `data` key.
  This key SHOULD be used for variable type (i.e. heterogenous) resource
  collections and MAY be used for constant type (i.e. homogenous) resource
  collections.

* Clarify different representations allowed for singular and plural resources.

* BREAKING CHANGE: Singular resource objects SHOULD now be be represented with
  JSON objects instead of arrays. This allows for symmetrical representations in
  request and response documents, as well as PUT/POST requests and PATCH
  operations. It also simplifies implementations which do not support batch
  operations (i.e. they can allow an object and not an array).

* Define URLs for resources, collections of resources and resource
  relationships. Allow for alternative URL definitions to be specified in
  responses.

* BREAKING CHANGE: Allow the baseline implementation of JSON API to operate via
  POST, PUT and DELETE alone (no PATCH required). This introduces brand new
  specs for updating resources via PUT and updating relationships via POST and
  DELETE requests to newly specified relationship URLs. It also specifies how
  resources can be created, updated and deleted in bulk (but only per type).

* Introduce alternative JSON Patch syntax for all operations. This builds off
  the current spec's approach to updating relationships. JSON Patch bulk
  operations are discussed.

* Introduce a "Filtering" section in "Fetching". Since we encourage keeping all
  resources accessible at the root level, it corresponds that root level
  filtering should be encouraged instead of filtering via nested routes.
  Furthermore, root level filtering is more flexible because it allows for more
  than one filter to be applied to a collection.

* Introduce a `clientid` key that can be used to correlate a resource on the
  client with a newly created resource on the server.

* Introduce error objects, which are specialized resource objects that MAY be
  returned in a response to provide additional information about problems
  encountered while performing an operation.
Fix header links.

Instead of hiding `a` elements except on hover,
display the ¶ tag as :after content on :hover.
This keeps the elements always on the page and
allows the links to work in all scenarios.
Clarify design goals

State balance between efficiency, readability, flexibility and discoverability.
Clarify that collections act as sets keyed by resource ID.
Remove heterogenous resource representations and non-uuid client ids.

These two aspects of the v1rc1 proposal have proven to be the most
controversial. They've been removed for now with the intention that 
they will be considered separately.
Add FAQ re: arrays vs. sets and the need for the linked object
Expand upon "reference document" concept in URLs section.
Incorporate @ahacking's suggestion to clarify the reference document section.
Merge pull request #237 from dgeb/v1rc1-simplified

JSON API v1.0rc1, simplified