Profiles are a means to describe additional semantics the JSON API media type, without altering the basic semantics.

Profiles are identified by URI, which ideally should dereference to a document that describes the semantics of the profile.

One or more profiles may be associated with the JSON API media type through the `profile` media type parameter. The application of profiles to a particular document can be specified by clients and servers  via the `Content-Type` header. The application of one or more profiles to a response can be requested by a client via the `Accept` header.

In order to require the application of one or more profiles, the profile(s) must be specified with the `profile` query parameter.

Any structural elements introduced by a profile can be aliased. This allows for better adaptability and composition of profiles. A new profile descriptor object is introduced which allows for declarations of aliases in a particular document.

Closes #1207

E.g., clarify that profiles can cover any implementation-specific query
params, not just sort/filter/page

…param values

This is key for servers that don’t want to add `Vary: Accept` for
better caching

Should be obvious, but worth saying

The link to the w3c tag terminology about backwards and forwards
compatibility is more precise than “evolve additively”, though it
doesn’t change the intended meaning

From 1195

Also add examples of profiles

Technically, this rule is required to make it legal to add even a new,
optional member to the timestamps object.

This commit just pulls the existing guidelines about authoring profiles
into a dedicated section, without changing any of the substance.

I’m pulling this out because there are a few requirements for authoring
profiles that I think are missing, and it was getting a bit messy to
have the rules for authoring profiles all mixed in with the rules for
using them.

Whoops.