is-on-https and insecure redirects

I believe this is the current summary. Please comment if I'm getting something wrong.

If an HTTP URL is tested in the CLI, even if it redirects to an HTTPS URL it will fail the `is-on-https` audit because the first request is insecure. It's arguable that this is correct (the first site indeed wasn't on HTTPS), but it can be an issue for automated testing where the redirect isn't necessarily material to what's being tested, and clearly the site *is* on HTTPS as soon as it's redirected. Additionally a human might notice the current log message warning of the redirect (or a `debugString`), but an automated system won't.

This is complicated by the fact that this is really only an issue in the CLI, since if testing in the extension or in DevTools the redirect would have already happened before hitting the "Perform an Audit" button and the `is-on-https` check would pass.

Steps we're currently proposing:
- [ ] relax `is-on-https` to allow a network-based redirect from an insecure origin to a secure one. This would include 30x redirects and HSTS-based ones, but not Javascript based ones. Add a `debugString` in this case that warns that, while passing, the first request was insecure.
- any other types of redirects allowed?
- can the insecure redirect be any of the redirects? e.g. if the redirects go HTTPS -> HTTP -> HTTPS

- [ ] add a "susceptible to a downgrade attack" audit (in Best Practices) that would warn when testing a site that passes the new `is-on-https` but passed through an insecure URL and suggests HSTS

- [x] We've discussed for some time having a prominent warning area in the LH report for top level issues affecting what Lighthouse can measure (for, e.g. [warning that the LH run was done with headless](https://github.com/GoogleChrome/lighthouse/pull/2920#discussion_r136440473), which will skew perf numbers). A warning could be put here in case of insecure redirects, e.g. the same as the `debugString` above or [the warning that's currently sent to the logger](https://github.com/GoogleChrome/lighthouse/blob/43e93bc71d66f479c50d0d0eca8de6807b39057c/lighthouse-core/runner.js#L40-L43) ("The URL provided should be on HTTPS. Performance stats will be skewed redirecting from HTTP to HTTPS.") - #1512

- [x] `redirects-http` needs to move to checking schemes, not `schemeIsCryptographic` #2363

Importantly, the warning is good to let humans know that something weird is going on with their test (e.g. they misentered the URL as HTTP), while the new downgrade audit is good to let machines (e.g. the HTTP Archive) know that something is still not ideal even while `is-on-https` is passing.