Tie accesskit root nodes to winit's WindowId instead of window entity

[UkoeHB]

Objective

• Allow accesskit root nodes to work even if window entities change. Motivated by bevy_worldswap.
• Improve code robustness by attaching accesskit root nodes directly to windows, instead of using window entities as a proxy.

Explanation

In order for accesskit to connect to a window, an Adapter is required. Adapters can only be created at the moment a winit window is initialized. Moreover, Adapters internally track a NodeId tied to a specific window. This means the NodeId in window adapters must be defined when windows are initialized.

Currently window adapter NodeIds are defined from the Bevy entities that are used to track each window. The entity bits are essentially used as a proxy identifier for the underlying winit window. This works just fine when there is only one Bevy world that uses a specific winit window. However, bevy_worldswap is a new, experimental, crate that allows you to swap the world that renders at runtime.

When swapping worlds, the new foreground world (i.e. the world that will render) needs to be hooked up to existing windows. This means moving window adapters between worlds. Transferring adapters is easy enough, but the problem comes when accessibility updates in the update_accessibility_nodes system. New accessibility node trees are attached to the current PrimaryWindow via the Bevy entity id. But since we swapped to a different world, windows now live on different entities, so accessibility will not work. This is a consequence of using proxy ids for window adapters instead of directly tying adapters to windows.

Solution

• Use winit's WindowId for accesskit root nodes instead of the Bevy entity that tracks a window.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[NthTensor]

I'd appreciate a more detailed justification for this change, or some discussion of the pros and cons of each approach.

[UkoeHB]

@NthTensor added an explanation.

As far as I know this is not a breaking change, because NodeIds are internal implementation details. I could be misunderstanding it though.

[NthTensor]

Fixed

[UkoeHB]

Closing due to won't fix conclusion from #12860.