RadioNodeList should be a live view

[pshaughn]

The concept of a live NodeList appears in several places, much like the concept of a live HTMLCollection. Currently, the only kind of live NodeList we have is for a ParentNode's children. Three other cases need a live one: the labels of a labelable element (issue #25391), the result of Document.getElementsByName (issue #25147), and RadioNodeList. [querySelectorAll and MutationRecord have NodeLists but are not meant to be live]

https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem step 1 and https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#dom-htmlformcontrolscollection-nameditem step 4 are the two places where a RadioNodeList can be created; both specify that it's live, so RadioNodeList should always be live.

The two specifications for what the RadioNodeList exposes do not seem identical at first glance, and the implementation might need two different states to cover them both:
"all the listed [form-associated] elements, whose form owner is the form element, that have either an id attribute or a name attribute equal to name, with the exception of input elements whose type attribute is in the Image Button state, in tree order."
" a live view of the HTMLFormControlsCollection object, further filtered so that the only nodes in the RadioNodeList object are those that have either an id attribute or a name attribute equal to name. The nodes in the RadioNodeList object must be sorted in tree order."

[pshaughn]

To clarify: the non-compliant thing Servo is doing here is that adding or removing nodes from the form won't update an already-created RadioNodeList that is supposed to be a live view. This is separate from the RadioNodeList's value, which is itself already live but is backed by a static collection of nodes instead of a live collection of nodes.

[jdm]

Marking this as high value since this seems like the kind of behaviour that existing web content could be relying upon (especially via getElementsByName and the named form getter) that would break.

[pshaughn]

There are indeed two cases, but the two lines I listed above are actually one case, as the only way to get an HTMLFormControlsCollection is backed by a single form element and excludes image-buttons.
The other case is https://html.spec.whatwg.org/multipage/forms.html#dom-form-nameditem step 2, in which the list contains only image-buttons. Even though we don't really have working image-button support, we do have the type="image" state itself defined, so we can implement and test the NodeList behavior for this case. I'm thinking RadioNodeList gets a Dom<HTMLFormElement> for the form that produced it, a DOMString for the name it's reflecting, and an internal boolean to indicate whether it's an image-buttons list or an everything-but-image-buttons list; other than that boolean it's highly analogous to Document.getElementsByName. so I can reuse a lot of what I did in #25428.