On one hand, it's a bit confusing that UIs can be arrowed around independently of tab/shift-tab. Arrow navigation doesn't feel as intuitive, as it isn't obvious where you'll land.
On the other, it's quicker to navigate between areas of the editor UI by arrowing up/down between controls, and may solve the issue of having to tab a million times to traverse all controls. This also allows for in-game UIs to be traversed using arrows and, quite probably, gamepads as well.
This eliminates the need to track and iterate through a separate array of `Accessible`s in `ScreenReader`.
The previous performance issues are resolved by ensuring that any nodes processed aren't children of the `ScreenReader` node. I don't know of another way to avoid triggering signals on a child node than checking ancestry and failing fast.
Tested with `HSlider` and has basic support for other widget types, but I'm only adding support for what I'm immediately using or can access via the editor.
This can barely be called "support." It reads all text as a single block. I'd like to at least be able to unfocus the `TextEdit`, but it's going to require a custom key. Ctrl-tab and Ctrl-shift-tab seem like good candidates, but the editor grabs those already.
Moving through every focusable widget by tab/shift-tab is very slow. This commit introduces the concept of groups--widgets that can be skipped through via ctrl-tab/ctrl-shift-tab.
Right now this only includes containers where all children are focusable, but I'll expand the definition of groups over time to make navingating to large areas of the UI easier..
When we unfocus, wait a second. If we don't have focus after the timer elapses, warp the mouse to the global coordinates.
This seems to restore some semblance of focus whenever it is unset, while not breaking the case where a focus is set and the mouse suddenly jumps, thus changing the focus again.
