Data guidelines for Web IDL iterable, setlike and maplike declarations

Web IDL has some higher-level declarations that result in multiple things being exposed on an interface, and it would be great to have some data guidelines for how to represent these.

They are:

• iterable<value_type> and iterable<key_type, value_type> result in @@iterator, entries, keys, values and forEach being exposed
• async iterable<value_type> and async iterable<key_type, value_type> result in @@asyncIterator and some other things being exposed.
• maplike<key_type, value_type> results in @@iterator, forEach, size, entries, keys, values, get, has, clear, delete and set being exposed
• setlike<type> results in @@iterator, forEach, size, entries, keys, values, has, clear, delete and set being exposed

Apologies for inevitable mistakes in the above list.

There's already some inconsistency in how such things are represented in BCD. Here, as a "Support of for...of" entry:

https://github.com/mdn/browser-compat-data/blob/1ca3bd9afdea60d0cbeb6f270274ce3d492824d0/api/FormData.json#L102-L104

And here, as the @@iterator symbol and other entries:

https://github.com/mdn/browser-compat-data/blob/1ca3bd9afdea60d0cbeb6f270274ce3d492824d0/api/StylePropertyMapReadOnly.json#L434-L436

What should we do?

Opinion: As a reader of the StylePropertyMapReadOnly compat table it's not super useful to know that @@iterator is individually supported, it's more useful to know whether for (const [prop, val] of stylePropertyMap) { ... } will work. Knowing that entries could be more useful, however. Perhaps there should be a grouping of entries to reduce clutter?

Start by reading docs/data-guidelines.md and compare the FormData.json and StylePropertyMapReadOnly.json examples linked in the issue. Review the discussion to determine whether iterable, async iterable, maplike, and setlike declarations should be represented individually or as groups; done means the chosen guidance is documented and the affected examples are consistent.