core(responsiveness): add element screenshot to INP diagnostic

[brendankenny]

part of #13916

https://crrev.com/c/3632661 added a nodeId for interaction events, so we can add it to the TraceElements gatherer and tell users which element they interacted with that caused the INP event. Right now it's just an outerHTML/snippet, but with #13983 fixed, it should get the element screenshot treatment (when available).

---

Possibly more controversial:

This PR combines the element screenshot with the thread-breakdown table introduced in #13982 in the same audit.

Typically we align audits with tasks, e.g. we don't have an inefficient images audit, we have optimized-images/modern-image-formats/image-size-responsive audits, because they all involve different types of tasks.

Trying to figure out what is going on with an INP result is a single task. Knowing what element was clicked on (or typed in) adds context to the thread-breakdown information, and wouldn't be helpful beyond an FYI as its own audit.

I was wishing for an auditDetails that just lets you have more or less a repeated auditDetails in it, with no special surrounding styling, and it turns out we do have that, we just never use it for anything: {type: 'list'} :) It was introduced for some of the JSON-LD audits in progress at the time, but then never actually used. From that PR:

we already have several audits using single-column tables to get an ugly list, and switching them to a dedicated list type (sometime in the future) would be great, so let's leave that path open to them. So:

export interface DetailsRendererList {
 type: 'list',
 items: DetailsRendererSnippet[]
} 

aka items still has to be an array of only snippets, but that will allow us to easily expand what's allowed in items in the future.

so we just need to expand the type of items allowed in a list. We also have never used the snippet details type/renderer, so I've removed it for now.

[brendankenny]

live report: https://lighthouse-kbs6iaa8z-googlechrome.vercel.app/gh-pages/viewer/?gist=20c1c4f5f44b50cb4ee9f65e3feb8a20

[connorjclark]

TIL about list too. Can you think of any other audits where we could be using that (or maybe combine into one "task" audit)?

[connorjclark]

nit: getResponsivenessElement -> getResponsivenessElements

[brendankenny]

nit: getResponsivenessElement -> getResponsivenessElements

Maybe I'll split the difference and keep the singular name but change it to return a single TraceElementData, then the caller can wrap it in an array like the lcp node id

[connorjclark]

was gonna suggest append over appendChild but I see we use it in so many places in report anyway. #13991

[brendankenny]

was gonna suggest append over appendChild but I see we use it in so many places in report anyway. #13991

it's always a good time to prefer append :)

[brendankenny]

TIL about list too. Can you think of any other audits where we could be using that (or maybe combine into one "task" audit)?

not any off the top of my head, but it seems like they must exist :) We should maybe go through in one of the bug bashes/eng syncs.

If we add CLS attribution, it may make sense to combine with layout-shift-elements

[brendankenny]

also added a note that in theory any details should work in a list, it's just repeatedly adding elements in the lh-details div, but in practice they may interfere with each other due to styling, or assumptions in details renderer (e.g. they're the only child in their parent), etc. Need to double check they work before adding another.