Parley's AccessKit integration is hard to integrate with some applications

Nobody has claimed this yet.

Expanding on what I brought up at [today's office hours](https://xi.zulipchat.com/#narrow/channel/359642-office-hours/topic/2025-03-20/with/507015077).

Parley's `LayoutAccessibility` API requires access to the root `TreeUpdate`, which it pushes nodes directly into. When trying to integrate this into egui, I ran into an issue: egui's AccessKit integration does not expose that `TreeUpdate`. It seems that in egui, the intended way to create an AccessKit node is through `Context::accesskit_node_builder`, which pushes the node into the `TreeUpdate` itself (technically, it defers doing that until later). [For reference, see the current code for AccessKit text interop](https://github.com/emilk/egui/blob/d54e29d3758f8abd0f97508ff89de46e739a0931/crates/egui/src/text_selection/accesskit_text.rs).

I've managed to work around this in my current branch by [creating a dummy `TreeUpdate` for Parley and then taking the nodes from it](https://github.com/valadaptive/egui/blob/7ae56db47538408a906c86e6378962118cd90b47/crates/epaint/src/text/text_layout_types.rs#L489-L528), then [overwriting the entire node that `accesskit_node_builder` gives us](https://github.com/valadaptive/egui/blob/7ae56db47538408a906c86e6378962118cd90b47/crates/egui/src/text_selection/accesskit_text.rs#L37-L58) but this seems a bit fragile and results in a lot of extra allocations.

@mwcampbell mentioned potentially changing Parley's AccessKit API to something callback-based. I assume this means something like Parley calling a provided callback once per node that it creates, which seems like a good API to me.

egui's `accesskit_node_builder` approach provides the node itself and requires all its properties to be instantiated within *its* callback, and integrating that with Parley seems like it'd require some gnarly nested callbacks--Parley would call a "node factory" function, which would call `accesskit_node_builder`, which would then call some Parley-provided function with the node that it created. Some extra flexibility on egui's side may therefore also be necessary.

Start with Parley's LayoutAccessibility API and the referenced egui accesskit_text.rs and text_layout_types.rs code, then compare how the root TreeUpdate and nodes are currently exchanged. Clarify the callback-based API shape and egui integration requirements; done should avoid the dummy TreeUpdate, whole-node overwrite, and extra allocations described in the issue.

Written by the indexing model from the issue text.