computeBaseline for WebViews - add WebViews to compat_keys

[NiklasMerz]

This PR adds WebViews to the by_compat_key items for each web-features. For caniwebview.com this is really useful as we can now use computeBaseline for web-features to show the status on the site.

Here is a built version of the data.json file:
data.extended.json

Should WebViews be included in the top-level browsers key and their status in the web-features?

Closes #3553

[NiklasMerz]

Screenshot that shows webviews are added to the browser list and the support keys:

[ddbeck]

Some general feedback on this idea, though I feel positively toward computing support summaries for webivews in general:

• The smaller problem is that doing this primarily via compute-baseline complicates the dist files: each .dist file gets modified to show the webview support information. Those dist files are how we review status changes to Baseline features and adding a lot of noise to those files would be… challenging. Fortunately, I think this is solvable. For example, we could refactor this to generate webviews data when we ingest dist files or when we build the release.

• This approach does reveal an assumption in the schema, which is a bigger problem. The implication is that the keys of features["somefeature"].status.support are the Baseline browser set. I don't think there's (yet) an appetite for modifying the Baseline definition to include webviews, so I imagine we'd get some pushback if we added browsers to the support object that do not contribute to a status.

  But since the goal of this work in the near term is to make it easier to build Baseline-inspired (or caniuse-inspired tools) that are distinct from Baseline itself, I think there are some avenues to make that happen. To me, the most straightforward seem to be:

  • Generate a separate parallel JSON artifact that doesn't make status claims (e.g., it generates data for every browser in BCD, but omits the baseline, baseline_low_date, and baseline_high_date fields).

  • Modify the schema, to separate the Baseline browser set from the non-Baseline browser set. For example, add something like features["somefeature"].status.support.noncore or features["somefeature"].extended_support, where data for browsers outside the core browser set goes.

[NiklasMerz]

I just refactored it to our latest discussion. The support info is now not part of support but gets a new property for non-core browsers. It's also non part of the dist files now.

Naming things is hard. I settled on ecosystem_support but I'm not that happy. The other suggestion I have is support_beyond but that's worse.
@ddbeck Or should we go with extended_support or support_noncore?

[ddbeck]

I think at this point I'd like to get some feedback from consumers about where they'd expect to find support data that is not used in setting a Baseline status. This might be a good topic to bring up at the next WebDX web-features call (one week from today, April 9).

[NiklasMerz]

Definitely! I'll make sure to be there. I have mixed feelings if this changes is expected by users as well and would love to find out if and how we can compute Baseline for non-core browsers most effectively.