Consider mechanism for persisting element data even when their original URL Metrics expire

As described in https://github.com/WordPress/performance/pull/1847:

This PR facilitates the ability for extensions to persist data outside of the URL Metric itself and in the postmeta of the od_url_metrics post type. This is required when data being collected in URL Metrics is not always available. For example, with Embed Optimizer, not every collected URL Metric will include the resized height for an embed since a user may not scroll down to see it in the viewport to cause it to be lazily-loaded. And in the case of Content Visibility, once an element has content-visibility applied, it is not longer able to be measured during detection unless, again, the user happens to scroll down to view the element that has CV applied. So we need to capture the initial height of the element in addition to the height of the element when users happen to scroll to it. Persisting this information in postmeta outside of URL Metrics is a way to do this. We should explore further if the core URL Metric construct should have a way to persist some data as new URL Metrics push out old ones, but in the meantime using postmeta as an ad hoc storage area is a way for us to experiment.

Embed Optimizer adds a resizedBoundingClientRect property to the element schema. This gets populated by a client-side extension when a Resize Observer detects an embed resize. Nevertheless, embeds outside the viewport are lazy-loaded. This means that if URL Metrics are collected by visitors who never scroll down the page, then this resizedBoundingClientRect property will not get populated. And even if it does eventually get populated in a URL Metric, when new URL Metrics are collected then the resizedBoundingClientRect will get lost as the new fresher URL Metrics displace the stale ones. Granted, this is not a big deal for embeds because if the embed is outside the viewport the first place so that it can be lazy-loaded, then there's likely not going to by any layout shift appearing to the user and thus no impact on CLS. The issue is more important for applying Content Visibility (as quoted above) since the heights of elements outside the viewport need to be set up-front in order to prevent scrollbar jank.

The Content Visibility plugin (as prototype to implement https://github.com/WordPress/performance/issues/1308), referenced above, solves the problem by persisting element data in the postmeta for the od_url_metrics post type. This works, but is it the best?

Start by reading PR #1847 and the Content Visibility plugin's use of postmeta for the od_url_metrics post type. Compare that approach with the URL Metric behavior described in the issue, including how newer metrics displace older data. Done means establishing whether core should provide a persistence mechanism and defining its scope.