Moving lazy tree initialization back into the core platform adapters

[mwcampbell]

I now believe that #179 was a mistake. The issue that motivated that PR, with the way I was doing lazy initialization before, was real. But I think I need to find another way to fix it. On Unix, an optimal implementation of AT-SPI is going to require that the Unix platform adapter directly support lazy initialization of the tree after the adapter has been instantiated. And even on Windows and macOS, this is ideally something we should delegate to the core adapters themselves, even for non-subclassing use cases. And as I noted in #179, on Windows, the UIA initialization marker is a wart in the API. Finally, I noticed just last night that I had accidentally made Windows initialization less lazy while working on #179, because handle_wm_getobject's behavior of aborting for some object IDs is only effective if that method itself does the lazy initialization.

I think what I need to do is combine the lazy tree source and the action handler into a single trait object, rather than using a generic closure for the tree source. I'll experiment and open a PR once I'm reasonably sure I've got the right design this time.

[mwcampbell]

I realized that my initial idea of combining the tree source and action handler in a single trait object doesn't actually solve the problem I was trying to solve in #179. The problem is that the old approach to lazy initialization, which I was using before #179 (and which I still have to use in the subclassing adapters), requires a second entry point where the toolkit or application needs to access its mutable state, or else a workaround where the toolkit has to initially return an empty placeholder tree (as eframe in egui does). The first entry point, of course, is the toolkit's main OS event handler. Combining the lazy tree source and the action handler in a single trait object doesn't change that. And that change would add unnecessary coupling; for example, on Windows, the action handler must implement Send but the tree source doesn't need to. So I'll discard that idea.

[mwcampbell]

I'm looking at this again. Thinking about it now, I might want to combine the action handler and the lazy initialization callback in a single trait after all. Separating them would allow the lazy initialization callback trait to avoid requiring Send on Windows, at the expense of a more complex API everywhere. Anyway, I now don't think the callback should be required to synchronously return a tree update. Instead, the callback should simply tell the application that the adapter needs a full tree update on the next frame. Then the adapter can provide an empty placeholder tree in the meantime, as egui itself currently does.