Add measures and logging for LCP diagnostics

[rviscomi]

The Optimize LCP guide describes how to instrument DevTools with additional LCP diagnostic info. It neatly logs each diagnostic in a table and uses performance.measure() to show them in the Performance panel.

Figure out whether upgrading to the attribution build in #110 is sufficient for logging the diagnostics, or whether we should add any extra table formatting like the example in the guide.

The measure feature should be gated behind the same User Timings option used by INP.

[tunetheweb]

Should be easy enough to edit this code after #115 is merged:

web-vitals-extension/src/browser_action/vitals.js

Lines 227 to 233 in dd624b9

	function addUserTimings(metric) {
	switch (metric.name) {
	case "LCP":
	// LCP has a loadTime/renderTime (startTime), but not a duration.
	// Could visualize relative to timeOrigin, or from loadTime -> renderTime.
	// Skip for now.
	break;

To do similar to what INP does, using the attribution breakdown data:

web-vitals-extension/src/browser_action/vitals.js

Lines 239 to 266 in dd624b9

	case "INP":
	if (metric.entries.length > 0) {
	const inpEntry = metric.entries[0];
	// RenderTime is an estimate, because duration is rounded, and may get rounded keydown
	// In rare cases it can be less than processingEnd and that breaks performance.measure().
	// Lets make sure its at least 4ms in those cases so you can just barely see it.
	const presentationTime = inpEntry.startTime + inpEntry.duration;
	const adjustedPresentationTime = Math.max(inpEntry.processingEnd + 4, presentationTime);
	performance.measure(`[Web Vitals] INP.duration (${inpEntry.name})`, {
	start: inpEntry.startTime,
	end: presentationTime,
	});
	performance.measure(`[Web Vitals] INP.inputDelay (${inpEntry.name})`, {
	start: inpEntry.startTime,
	end: inpEntry.processingStart,
	});
	performance.measure(`[Web Vitals] INP.processingTime (${inpEntry.name})`, {
	start: inpEntry.processingStart,
	end: inpEntry.processingEnd,
	});
	performance.measure(`[Web Vitals] INP.presentationDelay (${inpEntry.name})`, {
	start: inpEntry.processingEnd,
	end: adjustedPresentationTime,
	});
	}
	break;

However currently the extension uses the normal build, so ideally we'd move to the attribution build to get this. Anyone any concerns with this? I think it's a small bit extra processing, but will give us better data.