Contributing docs: explain compat_features versus tags

[ddbeck]

Fixes #1633

[autonome]

This removes the explanation of why this is optional, which should stay in some form:

In many cases, the corresponding browser-compat-data entries already map to the feature ID, and this is therefore not needed.

Also, this does not convey the intricacies of your answer in #1633:

The gist is that the contents of the authored YAML file (i.e., .yml) overrules other possible sources of data. This goes for status as well. If you provide a compat_features value, then the BCD tag is completely ignored. So either provide a complete compat_features list or none at all.

But maybe that's a lot for the table entry? Perhaps there's a better home for it, since this bit helped me understand the flow of the system as a whole better.

[ddbeck]

But maybe that's a lot for the table entry?

Yeah, I think it's too much for the table. Really, we need a standalone fields reference. Maybe the guidelines.md file needs to become that.

That said, I tried to bring my comment into the section that follows, about dist files. This effect now gets at least three mentions:

• In the table ("If compat_features is not set in…")
• In the Feature dist files section ("The contents of the authored YAML file overrules all other implicit sources of data.")
• In the Associate BCD keys with your feature section ("In this case, you don't need to explicitly list the BCD keys that your feature depends on.")

What do y'all think?

[jamesnw]

LGTM!