Specify how document.cookie diverges from [COOKIES] RFC

Currently the spec says

the user agent must act as it would when receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the new value encoded as UTF-8.

However, in the real world things like document.cookie = "foo" work and have an effect. There are probably many other possibilities; in general the RFC just has a grammar that things might not match, whereas I imagine browsers just accept anything and try to make sense of it, even if it fails to match the grammar.

@bsittler noticed this while working on some service worker cookie stuff, and previously it has come up in the jsdom project and its related tough-cookie helper:

• https://github.com/SalesforceEng/tough-cookie/issues/10
• https://github.com/SalesforceEng/tough-cookie/pull/49
• https://github.com/SalesforceEng/tough-cookie/pull/56

@Sebmaster and @inikulin led the charge for this in jsdom, so maybe they could help us spec the correct behavior for how document.cookie parses cookies? Alternately, looking at open-source browser code would get us pretty far.

This might be a compat issue if everyone hasn't managed to magically converge on a single behavior despite the lack of precise spec. Tentatively tagging as such for now.

Start with the document.cookie wording in the HTML Standard and the referenced [COOKIES] RFC. Compare the jsdom and tough-cookie issues and pull requests mentioned in the report, then consult browser implementations as suggested. Done means the document.cookie parsing behavior and its divergence from the RFC are precisely specified.