Composite features

[foolip]

With #970 we'll have a 5 features relating to font synthesis control. That makes sense right now because the individual bits are all relatively and with different Baseline low dates.

When all of these features are Baseline high, it would make sense to create a composite font synthesis feature, and for consumers to show that instead of the individual features by default. One could also think of it as hidden subfeatures that could be revealed.

As we continue to expand web-features I'm sure we'll find cases like this that are ~3 years in the past where this would make sense, so we don't have to wait for font synthesis to be widely available before tackling this problem.

Related discussions:
#217
#495
#648
#866

[foolip]

@ddbeck asked in #957 (comment):

There's an open question of how consumers would see a composite feature. Would the composite feature contain a list of compat keys, the union of the subordinate features? Or would the composite feature contain references to the subordinate features only.

We should probably enumerate the features that make up a composite feature with a field like composed_from. But I'm not sure if the computed status of a composite feature should be based on the union of all compat keys, or if it starts from the status of the features being composed without ever touching BCD.

If we want composed features that have the "initial support" and "later additions" aspect being discussed in #866, then I suspect sticking to web-features identifiers might be better. It'd be just another level of the same kind of summarization. Or perhaps we can have syntax that means "expand the BCD keys of this feature here" and that could allow us to efficiently point to the initial/later parts of a feature, despite the computation happening in terms of BCD keys.

[ddbeck]

Adding some terms to make this easier to find: feature combination, feature composition.