Wrap accessibility tree in Window node by default

[PoignardAzur]

Right now AccessKit kind of forces you to create a wrapper node/widget around your tree with the specific purpose of having the Window role. It would be nice if AccessKit provided that role for you by default, asking you to create Window nodes only for multi-window setups or other special cases.

[DataTriny]

I feel this would only make the API more confusing:

• Should the root node be exposed to implementors?
• Which ID should this node use? Should implementors be in charge of deciding or would we pick a value and ban users from using it for their own widgets?
• If the root node is not exposed, any node without a parent becomes a child of the root window. This makes it confusing to still talk about a tree then.

I think what is actually confusing is for toolkit authors to be in charge of supplying this window node, where this should really be the responsibility of the windowing provider. Glazier was doing just that if I recall correctly.

[mwcampbell]

The toolkit had to provide the window node when using glazier as well.

I think what should really happen is that accesskit_winit, or something like glazier, should automatically provide the window node. To make that work properly, I think we'll need to address the open design question of how to implement subtrees. A very early iteration of the AccessKit schema had subtrees, copied from Chromium, but we need to revisit that and figure out what will work best with our existing design. I think we're going to need subtrees anyway in order to properly make winit's client-side decorations on Wayland accessible.

[PoignardAzur]

I'm actually starting to lean the other way, and thinking we might want Masonry to provide the root node.

I'm especially thinking of multi-window cases, where in some cases, the root is a window, and in other cases it's a context menu or a picker menu. You would want to specify those.