Pass-through caching demo.

@kenjibaheux @jakearchibald @slightlyoff & co.:

Here's my initial attempt at a pass-through caching example, closing #31.

You can see a live demo of this code at https://rawgit.com/jeffposnick/samples/sw-pass-through-caching/service-worker/pass-through-caching/index.html
What would checking that the response is valid entail—just a null check (are there any cases in which `fetch()` resolves with null instead of rejecting?) or is there some specific property of response that should be checking? I see that there's a (termination reason)[https://fetch.spec.whatwg.org/#concept-response-termination-reason] defined as part of the response object, but I don't actually see it mapped to a property of what gets retruned in the current Chrome implementation.

Additionally, since Chrome returns [opaque filtered responses](https://fetch.spec.whatwg.org/#concept-filtered-response-opaque) for non-CORS requests, it's possible that `response.status == 0` is a legitimate, cachable response. So it's a tradeoff between never caching opaque responses or caching them unconditionally, and risking caching a transient error response.

That being said, I will at least check `response.status >= 400`, to avoid caching any non-opaque error responses.