Allow overlapping BCD keys without creating ambiguity

[foolip]

#1164 was caused by javascript.statements.import being part of both CSS modules and JS modules. In this situation, looking up a feature by BCD key finds two features, so consumers need something more to determine the status of javascript.statements.import.

The <source> element is a good illustration of the problem. The <audio> and <video> elements aren't yet in web-features, but if we add them, it would make sense for the <source> element (and HTMLMediaElement interface) to be part of both features, which shipped at the same time. But the <source> element is also a part of the <picture> element which shipped much later. Rather than picking a feature which gets to claim each BCD key, it would be good if overlap was handled gracefully.

This also has implications for #979.

[foolip]

It looks like javascript.statements.import is the only key that did belong to two features.

[foolip]

Rather than having rules that consumers need to handle for this rare situation, it would be good if we can bake the behavior we want into compute-baseline in #979. Something like:

• Our recommended way of getting the Baseline status of a BCD key is together with a web-features identifier, like computeBaselineForPartOfFeature('js-modules', 'javascript.statements.import'). This would clamp the dates so that the part of the feature is never claimed to be older than the overall feature.
• Theres's also a computeBaselineForCompatKey('javascript.statements.import') which would find the features that includes the compat key, and clamp to the oldest of the found featuers.

This would end up having the right effect on https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import at least.

[ddbeck]

#1204 is a step toward the ideas @foolip has mentioned above, though very incompletely.