consider adding attributes to track Cache API performance in a service worker FetchEvent handler

It would be nice to give sites some more insight into the time spent in a service worker FetchEvent handler. Currently browser mostly (see #119) provide these two PerformanceResourceTiming markers:

• requestStart marks when the FetchEvent is dispatched
• responseStart marks when the evt.respondWith() promise resolves

For sites using a service worker to offline their resources the fetch handler will often be a mix of various javascript and cache API operations like:

evt.respondWith(async function() {
  let c = await caches.open("foo");
  return c.match(evt.request);
});

Its not easy to associate the cache.open() time with the FetchEvent, but we could add PerformanceResourceTiming attributes like:

• cacheMatchStart marks the beginning of the cache.match() or cache.matchAll() that produced the Response passed to evt.respondWith()
• cacheMatchEnd marks when the cache.match() promise resolved the Response passed to evt.respondWith()

This would require setting some internal timing information on the Response. This information would be copied automatically across a Response.clone(). Any other consumption and re-packing of the Response would lose the information, though.

Review the related discussion in #119 and the PerformanceResourceTiming and FetchEvent concepts described here. Determine how cache.match() and cache.matchAll() timing would be represented and propagated through Response.clone(), then identify the specification changes and tests needed to define completion.