Draft: Add secondary action buttons as allowed child roles

[smhigley]

Resolves #1440

This is a proof of concept for allowing secondary actions in composite widget roles, and relies on the changes in #1454.

The relevant changes in this PR are these additional terms:

Controlled Element
A 'controlled element' is any element referenced by id via aria-controls.

Controlling Element
A 'controlling element' is any element with an aria-controls attribute which references the ID of the element.

And this addition to the allowed child roles of listbox, as an example:
<li><rref>button</rref> if <a>controlling</a> a child <rref>option</rref></li>

---

Preview | Diff

[JAWS-test]

I don't understand the concept yet: the button should be on the same level in the DOM as option (as a child of listbox)? I assumed so far that the buttons should be child elements of option and the listbox contains only options.
For me the following questions would be open:

• How is a listbox with option and buttons operated with the keyboard?
• Can the Accessbility APIs handle buttons inside listbox at all?

[smhigley]

Test page for support of nested vs. sibling action buttons is here: https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/
(cc/ @joanmarie)

(updated w/ actual link, because I fail at copy/paste 😅)

[smhigley]

Closing in favor of aria-actions (#1805)