[suborigins] Protecting Suborigined content from the rest of the origin

The current spec is great for isolating suborigined content from the rest
of the domain, and thereby preventing XSS bugs in the suborigined content
from being used to attack the rest of the domain. The opposite, protecting
suborigined content from being affected by XSS bugs in the rest of the
domain, is also very useful. A prime example is protecting password-change
and OAuth2 authorization pages from being attacked by XSS bugs elsewhere on
the domain.

The spec already provides several protections: 1) JS content in the same
physical original cannot directly access the DOM and 2) .postMessages()
messages can be discriminated by .origin. The one additional thing that we
need is a way to block non-suboringed JS from fetching using XHR from the
suborign. If non-suborigined content can fetch arbitrary content, it can
also typically fetch CSRF tokens and arbitrary sensitive information from
the suborigin.

I propose we extend the XHR spec to block returning of responses to JS if
the response contains a Suborigin header, and suborigin value does not
match suborigin name of the requester document.

This blocking is similar to how it is done for simple XHRs when the
response does not have CORS headers.

-Alex