Audit: does SW use offline-first caching? (or use s-w-r?)

While the test for a "200 OK" response to an offline navigation does a good job of confirming that a web app works offline, it doesn't check that navigations are handled via an [offline-first](https://twitter.com/jaffathecake/status/788289680735436800) strategy. Currently, a web app might use a [network-falling-back-to-cache](https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/#network-falling-back-to-cache) strategy for handling navigations and still get a perfect Lighthouse score, even though the network request will behave poorly in a lie-fi or a high-latency network.

Would it be possible to create a new test which checked whether the HTTP request used for a navigation was fulfilled via a network request, and fail that test if it was?

One wrinkle is that a web app which used a [stale-while-revalidate](https://developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/#stale-while-revalidate) strategy for navigations should pass the test, since the HTTP request was fulfilled from the cache. While there's a network request made, the network doesn't block the page from getting the cached result.

Based on my [last attempt](https://github.com/GoogleChrome/lighthouse/pull/578) at a related PR, I'm not sure that I have the familiarity with Chrome's debugging protocol to properly implement this, but I'm happy to review PRs, and provide some passing and failing test cases.

CC: @addyosmani @slightlyoff