Clarify relation to HTTP RFCs and similar

[JannisBush]

The standard does not specifies it's relation to the HTTP RFCs nor explicitly states what should be done in case of conflicts between the HTTP RFCs and the Fetch standard.

The fetch standard is stricter then the HTTP RFCs in several cases and e.g., dictates that a MAY is not to be implemented in browsers or that a SHOULD NOT is interpreted as a MUST NOT

• status code 300 MAY redirect according to HTTP but does not in Fetch
• Bodies in GET request are SHOULD NOT unless in HTTP and not allowed by Fetch (e.g., Proposal: Support GET bodies #83)

The fetch standard currently refers to the HTTP RFCs several times:

The goal is to unify fetching across the web platform and provide consistent handling of everything that involves, including:
...
To do so it also supersedes the HTTP [Origin](https://fetch.spec.whatwg.org/#http-origin) header semantics originally defined in The Web Origin Concept. [ORIGIN]

This specification uses terminology from ABNF, Encoding, HTML, HTTP, MIME Sniffing, Streams, URL, Web IDL, and WebSockets. [ABNF] [ENCODING] [HTML] [HTTP] [MIMESNIFF] [STREAMS] [URL] [WEBIDL] [WEBSOCKETS]

While fetching encompasses more than just HTTP, it borrows a number of concepts from HTTP and applies these to resources obtained via other means (e.g., data URLs).

The goal seems to indicate that Fetch is what browsers (should) implement and that contradictions with other specifications or options of other specifications do not matter. However, this is not made explicit and could confuse readers.