feat: Integrate CrUX data into performance trace summaries

[paulirish]

We upgrade the performance trace tools to include real-user experience data from the Chrome User Experience Report (CrUX).

https://developer.chrome.com/docs/crux
https://developer.chrome.com/docs/crux/methodology

Deets

• When a trace is stopped, the server now extracts the primary navigation URLs from the trace (determined by insightSets).
• It calls the public CrUX API to fetch field metrics (LCP, INP, CLS) for each unique URL/Origin.
• The formatting of crux data is handled by upstream TraceFormatter, but it looks like this:

Metrics (field / real users):
  - LCP: 2595 ms (scope: url)
  - LCP breakdown:
    - TTFB: 1273 ms (scope: url)
    - Load delay: 86 ms (scope: url)
    - Load duration: 451 ms (scope: url)
    - Render delay: 786 ms (scope: url)
  - INP: 140 ms (scope: url)
  - CLS: 0.06 (scope: url)
  - The above data is from CrUX–Chrome User Experience Report. It's how the page performs for real users.
  - The values shown above are the p75 measure of all real Chrome users
  - The scope indicates if the data came from the entire origin, or a specific url
  - Lab metrics describe how this specific page load performed, while field metrics are an aggregation of results from real-world users. Best practice is to prioritize metrics that are bad in field data. Lab metrics may be better or worse than fields metrics depending on the developer's machine, network, or the actions performed while tracing.

Privacy Considerations:

• Updates the server README to inform users that performance analysis tools may send trace URLs to the Google CrUX API.
• Adds a notification message to the server startup logs regarding the CrUX API interaction.

Doc: go/crux-in-bifrost
Fixes b/446630695