Separate related resources in a top-level `linked` object.

It's important to separate the primary resource from related resources because:

* It allows the client to easily identify the primary resource among related resources of the same type. This is especially important when creating a resource without prior knowledge of its server-assigned id.
* It clarifies issues like pagination that are specific to the primary resource.

This can be achieved by nesting related resources in a `linked` object. For instance:

```javascript
{
  "posts": [{
    "id": "1",
    "name": "Rails is Omakase",
    "links": {
      "author": "9",
      "related": ["2"]
    }
  }],
  "linked": {
    "posts": [{
      "id": "2",
      "name": "The Parley Letter",
      "links": {
        "author": "9",
        "related": ["1"]
      }
    }],
    "people": [{
      "id": "9",
      "name": "DHH"
    }]
  }
}
```

It's easy to imagine a scenario in which resources that are members of the primary array are secondary resources for other members of the primary array (e.g. people + friends). In those scenarios, primary resources should not be duplicated as secondary resources in `linked`. In other words, a single canonical representation of a resource should continue to be returned with each response.

[Closes #74]
Merge pull request #143 from dgeb/linked-resources

Separate related resources in a top-level `linked` object.
Fix compound document example for id-based APIs.

The example needs to be consistent with the example for url-based APIs and demonstrate the top level `linked` collection.
Merge pull request #144 from dgeb/linked-resources2

Fix compound document example for id-based APIs.
Introduce means to request related documents.

Describes how a server may optionally support inclusion of documents related to the
primary document either by default or via an `include` parameter specified in the request.

Adds a new `Fetching` section that parallels `Updating`. This section can be expanded
to include other means by which custom requests can be made.

Incidentally, some of the headings in the `Updating` section needed further indentation.

[Closes #19]
Merge pull request #145 from dgeb/include-related-documents

Introduce means to request related documents.
Introduce support for requesting specific fieldsets.

Describes how a server may optionally support requests for
specific sets of fields per document type.

[Closes #20]
Merge pull request #146 from dgeb/sparse-fieldsets

Introduce support for requesting specific fieldsets.
Use the correct content-type everywhere.

When we got our media type assignment, I forgot to actually update the
examples.

Thank you, @rkh! :heart:
Clarify when default fieldsets should be returned.
Merge pull request #147 from dgeb/fieldset-tweaks

Clarify when default fieldsets should be returned.
Ensure consistency in references to "a server"

This changes the structure of several paragraphs to avoid redundant references
to either "a" or "the" server.
Fix plurality of `author` paths.

 In a few instances, `authors` was used instead of `author`, even though it's a
 singular relationship. This change brings the "Fetching" section in agreement with
 the rest of the spec.
update examples of PATCH to use string "id" rather than numeric json-api/json-api#39
Merge pull request #153 from dgeb/fix-path-plurality

Fix plurality of `author` paths.
Merge pull request #152 from dgeb/a-the-i-o-u

Ensure consistency in references to "a server"
Merge pull request #155 from jcallaha/jcallaha-update-patch

update examples of PATCH to use string "id" rather than numeric
Clarified some marketing.

While the previous description was correct and succinct, if you don't know what's up, it was
pretty bad. This should hopefully be better for people who aren't familliar with all the details.
Adding examples to the front page.
Move status down to where it should be.