Support excluding individual BCD keys

[foolip]

Right now we have to provide a full compat_features list in order to override any issues with the tagging in BCD. Instead, let's have something like this:

name: WebUSB
spec: https://wicg.github.io/webusb/
caniuse: webusb
usage_stats: https://chromestatus.com/metrics/feature/timeline/popularity/1519
ignore_compat_features:
  - api.USBDevice.forget
  - api.WorkerNavigator.usb
  - http.headers.Permissions-Policy.usb

[foolip]

That example is what #842 would turn into. It's quite the difference!

[foolip]

I think it might be smart to put things like this in an overrides field that could be passed to computeBaseline pretty much as-is. Something like this:

name: WebUSB
spec: https://wicg.github.io/webusb/
caniuse: webusb
usage_stats: https://chromestatus.com/metrics/feature/timeline/popularity/1519
overrides:
  edge: "79" # hypothetically, if it was wrong
  compat_features:
    include:
      - api.Hypothetical.something
    exclude:
      - api.USBDevice.forget
      - api.WorkerNavigator.usb
      - http.headers.Permissions-Policy.usb

[Elchi3]

+1 to having ignored_compat_features as a field.

I think it would be good to require override/ignore reasons, though. Either as comments or as a field. For example, in #873, it was decided to include features up to forEach() but exclude other later subfeatures, because they are "non-essential" for "initial support". I think what should get ignored or overridden might be debatable in some situations, so having reasons is helpful for future people who need to make sense of it.

[foolip]

@Elchi3 do you think comments are enough for reasons? This makes it easy to have a block of things with the same reason, where doing it with a notes field would require repetition or a different structure (reason + list of keys).

[Elchi3]

I think comments might be enough, yes. Not sure how to require them exactly. Seems like that would be a task for the reviewer which might be okay for now (tooling telling authors what to do is often better and more reliable).

[Elchi3]

For additional transparency and providing reasoning, it might also be worthwhile to add the date that demonstrates the effect of ignoring features. Something like baseline_low_date_without_ignores: 2016-09-20.
I did investigate this in a review recently: #873 (comment)

[ddbeck]

It seems we've satisfied this need with compute_from (#1227) and publishing per-key generated statuses. I'm closing this, but we could reopen if we decide we need this again later.