Annotate features with special availability contraints and lifecycle events

[captainbrosset]

Opened after a discussion in #3477. In it, we wondered if it made sense to make an exception for WebGPU and make it Baseline Newly Available, as it had just become available in all engines under certain conditions.

While we decided not to make an exception, or change the definition of Baseline, we agreed to research what it would mean to annotate features with additional information that relates to special availability constraints, or important milestones of a feature. That's what the present issue is for.

See also #1038, which is about features that could be considered Baseline even if they are only available on mobile (or only desktop), because they only make sense there.

[captainbrosset]

Over time, we've discussed about adding annotations to features multiple times. Here are all the issues I could find about this:

• WebGPU can't be considered Newly Available without Firefox Mobile support which creates strange language needs for comms and deminishes Baseline branding clarity #3477 - Tell developers about important pre-Baseline feature milestones.
• Features that only make sense in one form factor should still be considered Baseline #1038 - Tell developers that a feature can be used (e.g. on mobile) even if not Baseline.
• Support notes #557 and line-clamp: set Baseline status #503 - Tell developers that even if a feature is not supported, it might still be implemented under certain conditions (e.g. vendor prefix).
• Editorial overrides: consider marking non-essential parts of a feature #485 - Tell developers which sub-parts of a feature were ignored in the status calculation.
• Make it obvious when something is in beta/preview/nightly #955 - Tell developers when a feature will become Baseline, and which pre-release browsers they can use in the meantime.
• Partial support and notes #915, Features with partial support appear as "Not supported" #2385, and "Limited availability" when not actually available? #1988 - Show devs more nuance for features that may appear unsupported but that are, in fact, partially supported.
• Baseline status regressions should require a note #1971 - Tell developers when a feature status regressed.
• Consider taking progressive enhancements into account for the Baseline status #2758 - Tell developers when they can use a non-Baseline feature as a progressive enhancement.