Consider storing abstract CWV data in URL Metrics not explicitly tied to tracked elements

Feature Description

Originally discussed in https://github.com/WordPress/performance/pull/1697#discussion_r1876359857.

The Image Prioritizer plugin is capturing LCP element information independent of the elements which are explicitly tracked for capturing in the elements of a URL Metric (which is indicated by returning true in a tag visitor). Image Prioritizer needs to do this for prioritizing the background image for an element which is applied with a stylesheet and not via an inline style. This is because no tag visitor would know which tag to capture in URL Metrics since there is no server-side indication that the element would be LCP or that it would have a background image.

All this to say, Optimization Detective only captures LCP information by storing isLCP in the element captured in URL Metric. It doesn't store the LCP element's image url or any other information about the LargestContentfulPaint. This means that Image Prioritizer on its own needs to store the url and id, en lieu of element it stores the tag name, and class name to better identify the element. This information could instead be captured and stored by Optimization Detective for Image Prioritizer to reuse. It could be stored in a top-level lcpElement property of a URL Metric, alongside the existing elements.

When it so happens that the LCP element was one of the elements captured in URL metrics, then the XPath of that element could be stored in the lcpElement property as well (as a nullable xpath property). As noted above, the xpath wouldn't necessarily be available since a tag visitor wouldn't know to mark the element for capturing in URL Metrics, so Optimization Detective wouldn't add a data-od-xpath attribute to the element. No longer would isLCP need to be stored with each item in elements since the XPath of the LCP element could be stored once in lcpElement. Determining whether one of the captured elements is LCP would then just be a matter of checking if the XPath matches lcpElement.xpath.

If there is a root lcpElement property it may then make sense to generalize this further to have a root metrics property which includes and lcp, inp, cls. For CLS, the LayoutShiftAttribution sources could be stored for potential reuse by Embed Optimizer (although I think the current ResizeObserver use in Embed Optimizer is preferable). The actual values for the CWV metrics could also be stored for use by a performance dashboard (https://github.com/WordPress/performance/issues/1324).

Start by reading the discussion on pull request 1697 and reviewing how URL Metrics currently store tracked elements and LCP information. Define the proposed shape for abstract LCP/CWV data, including how Image Prioritizer would reuse it and how completion would be verified across existing consumers.