Improve handling of redirects, navStart

This came up in the context of a [Lighthouse run on WPT](https://www.webpagetest.org/lighthouse.php?test=190515_NG_5141007153518f74a57e4234097397bd&run=1) ([wpt](https://www.webpagetest.org/result/190515_NG_5141007153518f74a57e4234097397bd/)) with 100% for the perf category but failing the `load-fast-enough-for-pwa` audit. This page loads a very large JS payload, then does client detection and redirects mobile browsers to a very lightweight "unsupported" page.

It turns out with throttling of both `devtools` and `provided` (with WPT's throttling), this site has a TTI of 0.6s because in those modes we measure from the last navStart (the redirect to the "unsupported" page) to TTI, not the initial navigation. `simulated` throttling measures from the first document request, so shows a slow TTI for the page (this is why the WPT result shows both a fast and slow TTI, because `load-fast-enough-for-pwa` [uses lantern TTI if throttling is `provided`](https://github.com/GoogleChrome/lighthouse/blob/641ab5170e2e8935752f38259506f61951deb258/lighthouse-core/audits/load-fast-enough-for-pwa.js#L67-L70))

There are a few things happening here that need to be handled:
- we don't track JS redirects with our [`finalUrl` system](https://github.com/GoogleChrome/lighthouse/blob/641ab5170e2e8935752f38259506f61951deb258/lighthouse-core/gather/driver.js#L1078-L1087). This means that the LH report doesn't reflect the actual URL you end up on, you don't get audit warnings to try out the finalUrl instead of the requestedUrl because the redirect could have been affecting your results, you don't get redirect info in the `redirects` opportunity, etc

The network protocol messages don't include JS redirect info, so we'll have to look elsewhere for the signal. Initiator info does look correct, however.

- Be consistent on a starting point for metrics and timestamps. Currently for `devtools` and `provided` we use the [*last* navStart with our frame ID](https://github.com/GoogleChrome/lighthouse/blob/641ab5170e2e8935752f38259506f61951deb258/lighthouse-core/computed/trace-of-tab.js#L33-L37) (which in this case is the "unsupported" page), but for lantern we use the the first document requested (for this case the initial heavyweight page that redirects to the "unsupported" one).

We include redirect information in an opportunity, but we non-lantern tries to measure the last page load. We should make a decision if we want to include these sometimes super-slow redirects against the perf metrics. Basically, are these perf metrics for `requestedUrl` or for `finalUrl` (assuming we fix `finalUrl` to account for JS redirects)?

- Need to split `NetworkAnalyzer.findMainDocument` into two methods (or something like that) :) All the lantern stuff uses it without `finalUrl`, at which point it [looks for the first document request in the network records](https://github.com/GoogleChrome/lighthouse/blob/641ab5170e2e8935752f38259506f61951deb258/lighthouse-core/lib/dependency-graph/simulator/network-analyzer.js#L450-L454). If you do pass it a `finalUrl`, however, it [finds the `finalUrl` document](https://github.com/GoogleChrome/lighthouse/blob/641ab5170e2e8935752f38259506f61951deb258/lighthouse-core/lib/dependency-graph/simulator/network-analyzer.js#L442-L448) even though it's ostensibly the *last* document request (in this particular case it works out to the same thing, but in the case of server redirects, lantern metrics and audits relying on the `main-resource` computed artifact will have different main resources)