w3c/webappsec-mixed-content

Based on the discussion in the public-webappsec thread starting at [1],
our face-to-face at [2], and our recent call at [3], this patch aligns
mixed content's checks with Secure Context's definition of potentially
trustworthy URLs.

Among other things, this means that `http://127.0.0.1/` will not be
considered mixed content when loaded in an otherwise secure page.

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2016Apr/0044.html
[2]: https://www.w3.org/2016/05/16-webappsec-minutes.html#item05
[3]: https://www.w3.org/2016/07/13-webappsec-minutes.html#item05

Closes w3c/webappsec-mixed-content#4.
Obviates w3c/webappsec-mixed-content#5.

Fixes #2.

This patch drops the 'potentially secure' term, as well as declartions
of 'security' (e.g. 'a priori insecure url' or 'insecure origin') in
favor or 'authenticated' or 'unauthenticated'. I hope this more clearly
expresses the notion I want to get across, and clears up ambiguitiy
with regard to Secure Contexts.

Fixes w3c/webappsec-mixed-content#1.

Closes w3c/webappsec#465.

w3c/webappsec#465

Fetch redefined things away from "context" and "frame type", towards
"initiator", "type", and "destination". This patch pokes at the
request-blocking algorithm as a first step towards dropping "context"
and "frame type" from this spec as well.

w3c/webappsec#465

This is a stab at resolving the definitional discussion had in [1].
I think it makes sense, but I'm just back from a week at the beach,
so who knows...

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0020.html

Fixes w3c/webappsec#434. Thanks, @tyoshino

As discussed in [1], it makes sense to pave the cowpath of allowing a
Service Worker to 'fetch()' a request made by a page directly, while
disallowing it from making requests on its own. Hopefully the current
patch is a reasonable reading of Fetch. :)

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0131.html

In [1], Anne noted that we ought to drop the phrase "That is certainly
the intent." from the Fetch integration section, and replace "TLS state"
with "HTTPS state" to match the spec.

This patch does both.

[1]: https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0059.html