Looking into two crashers revealed misconceptions in the initial Cookie
Store API implementation for change events in service works. This CL
reworks the API surface and brings it closer to other features.

The current API shape is that a SW version specifies the cookie changes
it's interested in by calling subscribeToCookieChanges() on the SW
global scope. getChangeSubscriptions() is available on the SW global
scope, and reflects the cumulative effect of all
subscribeToCookieChanges() calls during the install event.
Implementation errors aside, this API shape doesn't have a simple model
for continuously monitoring a cookie's change -- in the window between
deactivating an old SW version and activating the new version, there is
no obvious list of cookie change subscriptions.

The new API shape brings Cookie Store in line with the other SW APIs.
Cookie change subscriptions are associated with the SW registration, and
can be managed using
registration.cookies.{subscribe,unsubscribe,getSubscriptions}().

Unlike other SW APIs, the registration's subscriptions can be managed
from the SW itself, as well as from windows. We expect that most
applications will prefer to manage subscriptions from the SW code. This
exposes a rough edge -- a registration cannot be modified until the
first version of a SW is installed, so the methods listed above will
fail during a SW's first install event, but succeed during later install
events. We intend to evaluate the impact of this rough edge in an Origin
Trial.

Associated spec change: WICG/cookie-store#111

Bug: 729800, 956732, 963042
Change-Id: I106a7d9b2e50a7304c5ad126e0f699ecac1de531
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1837146
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Staphany Park <staphany@chromium.org>
Cr-Commit-Position: refs/heads/master@{#719476}