determine priority of `compat_features` keys vs keys in BCD generated features.

[autonome]

If you add a key to a feature's compat_features section, which already is in a feature that does not have a compat_features section, the dist script complains (rightly) that there are duplicate keys.

However, there are valid reasons to move a key from feature A to feature B, and treating this as a duplicate rather than a move prevents being able to do this.

Eg if we go ahead with a MessageEvent feature (unclear atm), it would have this:

compat_features:
  # Already generated in Broadcast channel.
  # Revisit once the "keys in impl or feature" question is answered.
  #- api.BroadcastChannel.message_event

[ddbeck]

I think the priority is unequivocal: compat_features in a .yml file are considered ahead of a BCD tag.

That said, it's annoying when moving a key from an origin feature to a destination feature. It's a multi-step process:

1. In the origin YAML file, check if there's a compat_features list. If there's not a list, then create one that duplicates the BCD tag.
2. In the origin YAML file, remove the key from compate_features.
3. In the destination YAML file, check if there's a compat_features list. If there's not a list, then create one that duplicates the BCD tag.
4. In the destination YAML file, add the key to compat_features.

There's nothing about this that could not be automated, once you know the key(s) to move and the source and destination. I'd welcome a PR adding a convenience script to /scripts for this task. I imagine something like mv-compat source-path dest-path compat-key … would be very handy indeed.

[jamesnw]

3. In the destination YAML file, check if there's a compat_features list. If there's not a list, then create one that duplicates the BCD tag.

I also would find it helpful to have a script that just creates a compat_features list that duplicates the BCD tag, in essence the reverse of migrate-to-bcd. This would be helpful when adding missing keys to a feature. I think all we would need to do is getting the compat_features from the .yml.dist, remove the comments, and add it to the .yml.