[Meta] Modular/distributed grammar definitions

There are a lot of cases where a certain value type / token consists of a disjunction of potential tokens, each defined in a separate section of the spec. However, there are still sections with "main" grammar definitions, that need to be updated every time new tokens are added or removed.

E.g.: Images:

<image> = <url> | <image()> | <image-set()> | <cross-fade()> | <element()> | <gradient>

Color 4:

<color> = <absolute-color-base> | currentcolor | <system-color> | <device-cmyk()>

<absolute-color-base> = <hex-color> | <named-color> | transparent |
    <rgb()> | <rgba()> | <hsl()> | <hsla()> | <hwb()> |
    <lab()> | <lch()> |
	<oklab()> | <oklch()> |
    <color()>

Color 5:

<color-space> = srgb | hsl | hwb | xyz | lab | lch | oklab | oklch

This is a maintenance overhead for editors, and makes it more likely for these definitions to get out of sync as tokens are added or removed (case in point: I just added oklab() and oklch() to the <color> grammar because they had not been added there too).

It should be possible to define a subtype entirely by adding a section, without also having to update centralized grammars. This also makes it possible to extend types in separate specs or levels.

Perhaps in addition to =, we could define a |= operator for grammars that means "whatever this token can be from the rest of the spec(s), plus these tokens". E.g., right now, adding OKLab and OKLCH needed edits not just to add their section but also to extend <color> and in Color 5, to extend <color-space>.

If |= existed, the entirety of the grammar changes that these introduce could be self-contained in their section:

<absolute-color-base> |= <oklab()> | <oklch()>
<color-space> |= oklab | oklch

oklab() = oklab( [<percentage> | none] [<number> | none] [<number> | none] [ / [<alpha-value> | none] ]? )
oklch() = oklch( [<percentage> | none] [<number> | none] [<hue> | none] [ / [<alpha-value> | none] ]? )

One could make the point that these summary grammars are useful (though not sure how useful they can be if out of sync). However, Bikeshed could generate them, similarly to how we generated indices, and that way they are guaranteed to be in sync.

Start by examining how Bikeshed represents grammar definitions and how its index-generation machinery produces summaries. Define what |= should mean across sections and specifications, then verify that distributed additions remain synchronized with any generated summary grammars.