SI: Don't pollute the list of global attributes.

As Anne suggested in [1], we now list all the elements and interfaces
which `integrity` attributes should be added to, rather than leaning
on the global list of attributes.

[1]: http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0062.html
SI: Note that servers should respond with `CC: no-transform`.
SI: Group use-cases for clarity.

1, 2, 4, and 5 are different takes on the same feature. 3 and
6 are distinct, and we should make that clear in the doc.
CSP 1.1: Merge `popup-src` and `worker-src` into `child-src`. Deprecate `frame-src`.
CSP 1.1: Whitespace cleanup.
CSP 1.1: 'blob:', 'filesystem:', etc. must be explicit.

Currently, we make URLs whose origin matches the protected resources
match 'self'. This was a poor decision, as these kinds of URLs
('blob://....', 'filesystem://...') can bypass CSP protections if they
are populated with data pulled from anywhere on the web via XHR, or
with raw strings.

This change ensures that developers will have to explicitly whitelist
'blob:', 'filesystem:', and etc. when constructing their policy.
Hopefully this means they will consider the risks involved.

Alternative proposals were:

1. Tie `blob:` URLs to 'unsafe-eval': This is a reasonable suggestion
   indeed. If someone wants to strongly argue for it, I'd be happy
   to revert this change, and tie 'blob:' to both 'self' and
   'unsafe-eval'. That has the advantage of making it more clear to
   authors exactly what they're whitelisting. It has the disadvantage
   of requiring authors to enable `eval()` on their sites in order to
   use Blobs, which is why I went with a different option in this
   patch.

2. Tie `blob:` URLs to `unsafe-inline`: I think this has too large of
   an impact. We don't want folks to need to allow inline script in
   order to use these types of URLs.