core(predictive-perf): predict FCP

[patrickhulce]

closes #3671
closes #3593

Adds prediction of FCP, similar to FMP but move the time boundary to observed FCP, remove the CPU layout tasks, and add in the EvaluateScript tasks of blocking scripts (which really could have been part of FMP prediction too).

I also added redirects support since FCP was more radically impacted by missing redirect support than FMP was. I dug into a lot of the larger error cases (where error was >1s) and at this point small differences should not be used for decision making.

Some notable examples:

• DevTools throttling limitations and approximation of just adding 600ms delay to everything greatly exaggerates impact of redirects (i.e. 3 redirects = 1.8 s instead of the correct result of ~500ms)
• Server response time was measured in seconds and had variability i.e. returned in 5s for unthrottled case but only 3 seconds in throttled case

Overall, we're about as accurate as we were with FMP, higher error at the tail but lower error for most sites. Further progress on accuracy will need higher fidelity throttling like WPT.

Accuracy comparison

Metric	Value on 99%	Value on 95%	Value on 90%
FMP - spearman's rho	.805	.833	.854
FCP - spearman's rho	.792	.832	.850
FMP - MAPE %	27.44%	24.11%	21.94%
FCP - MAPE %	29.03%	21.72%	19.65%

[paulirish]

I'm interested in keeping the FMP prediction, for now.

Until we have an actual midpoint metric replacement I don't think we can remove FMP entirely. (see also #3672)

[patrickhulce]

I'm interested in keeping the FMP prediction, for now.

I'm inclined to reduce churn in exposing until we have a concrete plan for what we expose ala #3761, but I agree so I changed to just add FCP and not touch FMP

[brendankenny]

This all looks good to me.

As we were talking about, maybe add extendedInfo entries for first approximations at estimates, even if they're only in the ballpark of where we're going with this? Happy to go with awkward names that discourage treating them as more than placeholders :)