[fetch] Mechanism to indicate "destination context" (#64)

This is a continuation of https://github.com/whatwg/fetch/issues/43: we've added language to set Accept, Accept-Language, and priority when request context _is not fetch_. However, this is not sufficient as we need to account for cases where request context _is fetch_. 

To address this, I'm proposing that we add some notion of "destination context", which is an optional attribute that allows the developer to indicate how/by whom the response is intended to be consumed. This value does not affect or override "context" value (which remains as "fetch"), but it can be used in the [fetching algorithm](https://fetch.spec.whatwg.org/#fetching) to set the appropriate request headers and priority. Optionally, this allows the UA to also enforce how/where the response is consumed.

Why not just override context? Because that would allow fetch() to bypass connect-src, and we also lose the initiator context -- e.g. within ServiceWorker I'd like to distinguish between `<img>` initiated requests and prefetch initiated image requests.. both have same destination context, but may need different processing logic.

---

1. I want to make an image request (https://github.com/slightlyoff/ServiceWorker/issues/279):
 * `Request({url: '/whatever.png', destinationContext: "image"})`
   * The request `context` is set to 'fetch': request is subject to connect-src.
    * The request `destination-context` is set to 'image', which is used to initialize Accept, Accept-Language, and request priority.

1. I want to prefetch an image asset:
  * `<link rel=prefetch href=/other.png as=font>`
    * The request `context` is set to 'preload'.
    * The request `destination context` is set to 'font' (via `as`, or whatever we call it), which is used to initialize Accept, ...

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/64