New audit: element-timings

Much like the `user-timings` audit, a `element-timings` audit would surface moments when user-specified elements have rendered, using the [Element Timing API](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceElementTiming).

There's a trace we can extract for these timings. See:

```html

hello

text here

```

```json
{
"args": {
"data": {
"elementId": "text-id",
"elementType": "text-paint",
"identifier": "connorme",
"loadTime": 0,
"naturalHeight": 0,
"naturalWidth": 0,
"rectHeight": 18.5,
"rectLeft": 8,
"rectTop": 42.5,
"rectWidth": 56,
"renderTime": 11,
"url": ""
},
"frame": "CD6D61E3FC5C6419A2C70D139EFAEF80"
},
"cat": "loading",
"dur": 5,
"name": "PerformanceElementTiming",
"ph": "X",
"pid": 74514,
"tdur": 5,
"tid": 259,
"ts": 117917914119,
"tts": 1061423
}
```

- We need a gatherer: `ElementTimings`
- And an audit: `element-timings`
- It should work for navigation and timespan modes
- If possible, in the end phase of the gatherer we should try and find all of these elements in the page so we can create `NodeDetails` (so we can show them alongside the loadTime values).
- - Ideally this would be done by taking a node id from the trace event and adding to the `TraceElements` artifact. But the trace is missing that info, so let's just add the node details to `ElementTimings`.
- - This is the only reason we need a new gatherer/artifact, unlike `user-timings` which just reads the trace directly.