Implement all possible AccessKit text properties

[mwcampbell]

Parley now exposes the following text-related properties when building AccessKit nodes from a layout:

• Font family
• Font size
• Font weight
• Font style (AccessKit currently only supports italics)
• Alignment
• Language

Callers can expose additional properties derived from the brush(es) for each style, such as foreground color and text decoration styles and colors.

[mwcampbell]

I'm aware that there ought to be test coverage of Parley's AccessKit integration. Ideally we'd do something like snapshot testing, but using JSON serialization of AccessKit trees as the snapshots. Thoughts on how to do this, and whether that should block this PR?

[nicoburns]

Regarding the Brush, I believe that long-term plan is for it to become just a user-specified ID that won't hold color information (or "paint" information in general) directly. In fact, this is already the case in Blitz's usage where we use the following type for Brush:

pub struct TextBrush {
    pub id: usize,
}

This is an important optimization as it allows us to avoid reshaping the buffer (which is slow) just because the color of some text changed (for example, in response to a mouse hover event) which does not otherwise require reshaping. For the same reason, Blitz is also not pushing underline or strikethrough information into Parley, and is "late binding" it using the ID stored in the Brush similar to color (and I would anticipate those properties being removed from Parley in future).

I would recommend that this PR reworks things so that the build_nodes method accepts a callback that maps from Brush (or Style<Brush>) to color and whatever other properties AccessKit may need (perhaps to Option<T> instead of T in case the user doesn't have useful color information?).

[mwcampbell]

Can we even assume, then, that all style changes within a run will be visible to Parley? Or is it likely that some style changes will only be visible to the caller when it's drawing cluster by cluster? In the latter case, I don't know how Parley would split the text into AccessKit nodes. If that's the case, maybe AccessKit integration doesn't belong in Parley at all, as much as we want to factor out reusable accessibility implementations.

[mwcampbell]

@nicoburns I've refactored the PR as you requested, to avoid modifying Brush or assuming that it directly contains color information.

[mwcampbell]

I see now that my previous approach wouldn't have even worked with Masonry, which now defines a BrushIndex type. I've validated the new approach with a WIP Xilem branch (note: updating AccessKit broke the Masonry test harness, so one function in there is temporarily stubbed out until we add a missing public API).