Add guidance on IDL attribute design

[rahimabdi]

Closes #11078

This PR provides guidance in the "Common DOM Interfaces" section on designing IDL attributes with appropriate types via a new "Designing IDL attributes" section. I also moved the following existing spec note on FrozenArray<T> naming to this new section as it fits better:

Reflected IDL attributes of this type are strongly encouraged to have their identifier end in "Element" for consistency.

[annevk]

Thanks for writing this up!

[annevk]

I think I would invert the advice. Given the types of content attributes we have, how would you go about best reflecting them. Because I think that's the question someone reading this is trying to answer, right?

I think we should also cover nuances such as "limited to known values", which we'd like to see used for new attributes.

[rahimabdi]

@annevk Got it, I've rewritten this introductory section to clarify that the content attribute informs IDL attribute reflection, and also included a note on encouraging "limited to only known values". I've also updated the title of this section to be "Designing attributes" if you think that's a better description (since it doesn't focus on just the IDL side).

[annevk]

This does seem like an improvement. But the majority of the advice is still centered around IDL types instead of content attribute types?

I would instead expect that we start with the content attribute types and then guide people towards the best IDL types. To sketch:

• If you have a boolean attribute, use boolean.
• If you have an enumerated attribute, use DOMString, "limited to only known values", and in rare cases it might be appropriate to use DOMString?.
• If you have a string, use DOMString.
• If you have an ID reference, use Element
• If you have a list of ID references, use FrozenList<Element>