Alternate CORS design

[annevk]

The primary goal is to require some change to the server so it simply cannot echo the Origin request header and call it a day.

With Sec-Suborigin (see #72) request header giving the suborigin identifier this could be made as simple as requiring that Access-Control-Allow-Origin specifies [Sec-Suborigin header value] [Origin header value] (i.e., separated by a space). The Origin request header would still contain the same value it has today (what's called "physical origin" in the current draft).

This has the additional benefit of still allowing requests to responses that always specify *. It seems not allowing such responses to be read unless they add another header (as the current draft proposes) would give quite a bit of motivation to not use suborigins.

Additional CORS preflights will hopefully be solved with Origin Policy.

(For the purpose of the "can we generalize this" discussion: I don't think it makes sense for Origin Isolation to alter the CORS setup (introduce an additional request header and require its value to be serialized into Access-Control-Allow-Origin somehow). That would make adoption of Origin Isolation needlessly complicated (due to all external servers needing to be aware of it) for very marginal benefit.)

[annevk]

@estark37 should probably double check my assertions about Origin Isolation above.