New audit: prioritize-lcp-image focusing on Priority Hints

**Feature request summary**

**tl;dr** rename the `preload-lcp-image` audit to `prioritize-lcp-image`, and update it to recommend the use of [Priority Hints](https://chromestatus.com/feature/5273474901737472) (shipping in Chrome 101) in cases where the LCP image is found within the main document but queued after other resources.

**What is the motivation or use case for changing this?**

Currently, the `preload-lcp-image` does not apply to cases where the LCP image was discoverable from within the main document ([see relevant audit logic](https://github.com/GoogleChrome/lighthouse/blob/v9.5.0/lighthouse-core/audits/preload-lcp-image.js#L56-L57)).

This potentially misses a big opportunity for sites to improve LCP because in many cases—even though those elements are discoverable from the main document—they're fetched with a low priority and often end up queued up waiting for other resources to finish.

Here's an example of that happening on [httparchive.org](https://httparchive.org)

In this screenshot you can see that the LCP image (the red outline) is discovered immediately, but it's assigned a "low" priority, so it still gets queued after other resources (e.g. font/stylesheets). In other words, there is clear opportunity to start loading the LCP image sooner, but Lighthouse currently does not highlight this opportunity.

If this site were updated to use Priority Hints and added `fetchpriority="high"` to the LCP image tag, the trace would look like this:

Notice how now the image is fetched in parallel with the fonts and stylesheets, and LCP happens at the same time as FCP.

As for what the _opportunity_ value should be: my suggestion is to take the delta between the `startTime` of the first resource and the `requestStart` of the LCP resource. Note that I recommend looking at `requestStart` rather than `startTime` for the LCP resource because `startTime` can be the point when the resource was queued (as in the first screenshot above), and the time that's important is the time the network request started.

**How is this beneficial to Lighthouse?**

The current `preload-lcp-image` audit misses lots of opportunity to improve. I recently analyzed all mobile page loads in HTTP Archive where LCP was an image (5M pages) to look at the time delta between when the first resource started loading and when the LCP resource started loading, and those times were surprisingly high.

| Passed `preload-lcp-audit` ? | AVG time between 1st resource start and LCP resource start as a % of total LCP time |
| --- | --- |
| TRUE | 38.4% |
| FALSE | 55.5% |

This table shows that pages that pass the audit are doing better than pages that do not pass it, but even for pages that pass the audit, a substantial amount of total LCP time is spent waiting for the LCP resource to start loading.

cc: @paulirish since we discussed this yesterday.