Improve LHR API shape for downstream consumers

[paulirish]

We have downstream consumers of Lighthouse data that want to use the details within extendedInfo and/or details.

However there are a few problems that make it difficult:

• details currently ships mostly strings like "42 ms". consumers gotta parse a number out of there. :/
• grabbing data from details requires relying on array indices and looking up those locations from a itemHeaders (which also doesn't offer reliable key names)
• extendedInfo we've never made promises on, but much of the good stuff is there. (we know, as we use it almost exclusively for unit tests)
• the two overlap awkwardly.
• probably some more.

Fixing this is a breaking change (Hello #4333!), but it's worth it.

Background doc: AuditResults Data format discussion

[paulirish]

Current Plan:

1. core: improved consumption of audit.details #4384 ships fewer strings in the LHR
2. core(lhr): overhaul LHR details, introduce details.summary #4616 makes details accessible by property
3. core(lhr): strictly numeric scores, add scoreDisplayMode #4690 change score to be 0-1 numeric in the LHR always. scoreDisplayMode forces how it's displayed
4. make list a table
5. make cards a table
6. do fallbackKey/fallbackType for multi-typed columns (code snippets sometimes instead of URLs)
7. Remove extendedInfo (and update all those tests)
   • We'll also need to take inventory of extendedInfo data that's currently not in the associated details block, but should be. (here's what HA uses, what brendan uses, what patrick uses)
8. We're discussing a load-metrics audit that contains all timings/timestamps in its details, so all the things don't need to reach into FMP.extInfo

[paulirish]

First build from this 3.0 effort. The build is based on this branch, which is 3 trivial commits beyond #4616.

lighthouse-ext-background.js.zip