New entry type: "new minor web-exposed feature with prior consensus"

[chrishtr]

We should add a new feature type for minor features that are:

• In the carve-out categories specified at https://bit.ly/blink-signals (currently TC39 3, WebAssembly stage 4, or Khronos standardized-as-\described-in-the-signals-document, but potentially WebGPU in the future)
• Have no significant compat, interop, or XFN review (security, privacy, debuggability, enterprise, testing) issues
• Is a small enhancement to an existing feature

For this new feature type, the following will be different from a typical I2S:

• PSA to blink-dev instead of intent-to-ship
• No TAG review required
• No vendor signals required
• Explainer can be brief (but is still needed)
• XFN review chips on chromestatus will automatically be started with "N/A"

The following will be the same as a typical I2S:

• XFN reviews will still happen and may be overridden by their reviewer to not be N/A
• API owners may raise issues on blink-dev in response to the PWA that might end up upgrading to a full I2S if there were unforeseen complications
• Specification and evidence of resolving feedback requirements are unchanged
• Developer need evidence still required
• In general, other I2S fields still need to be filled out in chromestatus.

[jrobbins]

What should be the description text shown next to the radio button when creating a new feature?

[chrishtr]

What should be the description text shown next to the radio button when creating a new feature?

I sugges the link to a page (that doesn't exist yet, but I can create it) on the chromium site that explains exactly which features get this treatment, and say "only choose it if your feature meets the requirements described there"

[jyasskin]

This conflates two different ways that a feature could differ from the norm, and I'm not sure we should use a new feature type to implement it.

1. Features with a carve-out on https://bit.ly/blink-signals or https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/. The tool should detect these based on the location of the spec and its metadata, and apply the exceptions whether or not the feature is minor. #3401 asks for some of this.
2. Minor features. Even features without a TAG review or signals exception could have only minor compat and XFN implications.

Making this a new feature type means feature authors have to commit to it very early and can't correct any mistakes without re-creating the feature. Both the carve-out status and the minor-ness of the feature could change during its development, for example if the API owners raise issues on blink-dev. I don't want to force feature authors to keep an inaccurate feature type after that happens or to re-create their issues.