Attempt to implement AccessKit inside the window crate

[DataTriny]

As the PR title suggests, this is neither fully working nor complete. I think it can be a starting point nonetheless.

Relates to #913

Current status

The async example is working correctly on Windows. I tested it on Windows 11 with NVDA and Narrator (two free assistive technologies).

Issues encountered

• The WindowEventSender cannot be shared so when accessibility-related events come from the system, I had to place a message into the window loop so the event could be dispatched to the app later. Although not elegant, this approach can work on Windows, and probably on X11 as well, but I think there would be no way to replicate it under Wayland. I haven't really checked on macOS.
• There is no way for the app to respond to a WindowEvent: when accessibility is first requested, I had to instruct AccessKit to generate a placeholder accessibility tree, until I can push the real one later. Another option would be to have a dedicated callback on Window to build the initial accessibility tree, but then the entire app state must be shared.
• WindowOp::update_accesskit_if_active cannot take the app state in its closure because its signature impose new restrictions that clashes with, for instance, the glium::Context in the async example. This also mean that the WindowOp trait is not object safe anymore, which will be an issue with the real wezterm app.

Overall, adding accessibility support to the windowing crate of wezterm would first require some architectural changes. I hope that this proof of concept can help shape the future of a nice, accessible, terminal emulator.