Allow precaching "repair" when using subresource integrity

[jeffposnick]

R: @tropicadri

Fixes #2858

Although unexpected, there are edge cases where the precache might not be in an inconsistent state, most likely due to a developer manually deleting something in DevTools.

When this happens, workbox-precaching defaults to falling-back to using a network response (assuming the device is online) when there's a precaching miss. Up until now, workbox-precaching hasn't attempting to use this network response to repopulate the precache, because there are no guarantees that the network response corresponds to the version of the asset specified in the precache manifest.

However, if the precache entry includes an integrity property, then subresource integrity guarantees that the response does correspond to the same version of the asset in the manifest. So it should be safe to "repair" the cache with that response.

(The revision field can't be used for this purpose, because while it's traditionally set to the hash of an asset's content, it could theoretically be set to anything, and it would be much too expensive to calculate the hash of the response body via JavaScript at runtime.)

[jeffposnick]

(Actually, hold off on the review. I noticed something that needs to be changed when testing locally.)

[jeffposnick]

...I realize now that the code in this PR will work if there's an integrity property on the actual request being made, but the integrity information from the precache manifest is being ignored. I need to find a clean way to pass information about the precache manifest contents (which is stored in PrecacheController) to the code that handles requests (which is in PrecacheStrategy).

[jeffposnick]

I've got a more robust approach, but it's blocked on #2914 (we need to be able to check the integrity property of the incoming request in the PrecacheStrategy, but without that PR, it's lost).