Add ServiceWorker

[autonome]

Large feature, since that's how most of the references treat it, and we can break out smaller pieces later.

Things like Cache are instrumental to the core functionality, whereas WindowClient might make sense to break out.

Computed status to line up with Caniuse.

[captainbrosset]

Not approving just yet because I think others should review too. But I don't really have any major comments other than:

• A suggestion for the description.
• A suggestion for pinning the compat data on keys that I think make more sense.
• An agreement that Client and WindowClient make sense here, I've never seen them be used in other contexts than in service workers.

[captainbrosset]

I'm approving this because I don't think there's a subset of the keys here that form a separate feature. And if so, we could always extract them later.

I did a bit of googling about the Cache API, and every page I could find talks about it in the scope of service workers. In fact, search for "cache API" -service basically only returns results from other libraries, languages, or frameworks. This comforts me in thinking that this feature is the right home for the Cache and CacheStorage APIs.

I see you've asked the serviceworker group for feedback, which is great.

[autonome]

Thanks @captainbrosset, if we get feedback from the spec folks, I will file followup issues and address there.

[autonome]

Capturing the feedback from the ServiceWorker standards folks:

Not sure how to read that pull request, but I would definitely not group the "Caches" API with the rest of service workers. While it was designed to be convenient to be used in conjunction with service worker fetch events nothing about it limits it to that use case, and really the only reason it's in the same spec is because nobody has done the work to split it off, not because it logically belongs here (i.e. see w3c/ServiceWorker#879).

Sounds like no action at this time, but once that work happens that the cache parts can be split out.