Land experimental responsiveness metric in user flows

The new [responsiveness metric](https://web.dev/responsiveness/) has mostly settled and so we want to include support for it in situations where there can be (real or automated) user input.

The steps foreseen:

- [x] add the high-percentile responsiveness metric for timespans - #13917
- [x] add a metric N/A state (that may not be `notApplicable`) in the report perf category renderer for when there was no user input in the trace - #13981
- [x] add an `interactions` audit for debugging responsiveness, e.g. here are the keypresses with the slowest response, here's the breakdown of what was blocking the response (time in script, layout, paint, etc) - #13982
- [x] Add `relevantAudits`? Would be similar to [TBT's relevantAudits](https://github.com/GoogleChrome/lighthouse/blob/c84ccddc677c9c74669ea30004f3dfdab973d5c1/lighthouse-core/config/metrics-to-audits.js#L32-L42) - #13982
- [ ] add to navigations if interactions present in the trace, but as a diagnostic audit, not a metric
- [ ] timespans don't yet support simulated throttling, but navigations do. Investigate if simple CPU multipliers are enough to get simulated numbers or if more sophisticated lantern simulations are needed
- [ ] `yarn update:flow-sample-json --rebaseline-artifacts Trace` to update the sample flow trace for the new EventTiming trace events (see https://github.com/GoogleChrome/lighthouse/pull/13979#discussion_r868407873)