Further evaluate default thresholds for enqueued assets

#25 introduced a Site Health module that warns if the enqueued CSS or JS files are too many or if they are too large. But what is "too many" or "too large"? The original thread where the current (preliminary) thresholds were defined (mostly to have something to start with) begins in https://github.com/WordPress/performance/issues/25#issuecomment-996561242. We can now use this issue to discuss and evaluate further and once we have come to a conclusion, either adjust the thresholds or just close this issue.

To summarize, the thresholds (i.e. anything above will trigger a warning) of the current implementation are:

• 10 CSS assets
• 100KB of overall CSS enqueued
• 30 JS assets
• 300KB of overall JS enqueued

These values were initially decided on based on the metrics from https://almanac.httparchive.org/en/2021/javascript#how-much-javascript-do-we-load and https://almanac.httparchive.org/en/2021/css#usage (see https://github.com/WordPress/performance/issues/25#issuecomment-1002804735 for more context). Let's see whether they actually hold up with further evaluation or where it might make sense to adjust them.

Aside: Note that all of these values can easily be changed (e.g. for testing) via filters perflab_aea_enqueued_scripts_threshold, perflab_aea_enqueued_scripts_byte_size_threshold, perflab_aea_enqueued_styles_threshold, and perflab_aea_enqueued_styles_byte_size_threshold.

cc @audrasjb @manuelRod

Review issue #25 and its linked discussion, then compare the current CSS and JS asset thresholds with the referenced HTTP Archive data. Evaluate whether the four thresholds should change; done means proposing and implementing adjusted values through the existing threshold filters, or documenting the conclusion and closing the issue.