Clarify CacheStorage behavior in data: URL workers

#687 noted that the spec was unclear regarding how self.caches and CacheStorage in data URL workers should be handled, and the resolution to that issue was to add the SecureContext web IDL attribute to self.caches and CacheStorage. I don't think this sufficiently addresses what to do in the case of data URL workers, though, because AFAICT data URL workers can be considered a secure context. For instance, if a worker is created from a data URL by https://example.com/, per [1] it seems like the worker would also be considered a secure context.

As currently written, it seems like the spec indicates that self.caches and CacheStorage should be exposed for data URL workers in secure contexts, but all of the functions should fail because:

• the CacheStorage interface member functions all use relevant name to cache map [2]
• relevant name to cache map uses obtain a storage key [3], which will "returns failure" if the environment has an opaque origin
• data URL worker environments have opaque origins [4]

It's unclear to me given the current spec language what effect the 'obtain a storage key' failure should have.

As discussed in #687, perhaps it'd be worth updating the spec to just not expose self.caches and CacheStorage in the context of data URL workers? This is what Chrome does today.

[1] https://html.spec.whatwg.org/multipage/webappapis.html#secure-contexts
[2] https://w3c.github.io/ServiceWorker/#dfn-relevant-name-to-cache-map
[3] https://storage.spec.whatwg.org/#obtain-a-storage-key
[4] https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object

Start with the Service Worker spec's CacheStorage exposure and the definitions of “relevant name to cache map” and “obtain a storage key,” then compare the linked HTML worker-environment and secure-context rules. Done means the spec explicitly resolves whether data URL workers expose self.caches and CacheStorage and what their operations do when storage-key creation fails.