feat: Expose the class name property

[mwcampbell]

As far as I know, only UIA on Windows has such a property. But this simple feature is helping me debug my GTK AccessKit integration, since it makes it easy to find the GTK class of any accessible object, e.g. via NVDA+F1.

[DataTriny]

I can easily see how this can be useful when debugging. Apart from this very specific usecase reasons why ATs would need that aren't very appealing to me. I'm pretty sure NVDA relies on it to patch some broken widget implementations, but I don't think AccessKit should encourage this way of dealing with issues. I think this information is too deep in UI toolkits internals to be exposed. Furthermore with other programming languages UI toolkit developers will have to resort to expensive type reflection to provide this.
My opinion would be to entirely drop the property from our schema.

[mwcampbell]

We always have to be pragmatic about things like this. The goal is as much accessibility as possible, by any means necessary. That includes workarounds implemented by the screen reader. If a screen reader workaround based on a widget's class name could help a blind person get or keep a job, then it's worth it. Of course, it won't be practical for all toolkits to expose this property, but we should make the option available.

[mwcampbell]

Another argument for exposing the class name: For toolkits that can do it in a generic, low-overhead way, as GTK can, it gives Windows screen reader users, and maybe Linux screen reader users in the future if the Newton project is successful, an easy way to add more information to their accessibility bug reports.

[DataTriny]

I think the bug report use case would be better served by having a good implementation of the Debug trait for Node, something I'm interested in tackling.

But I don't want to block this any longer. Implementors who can easily provide this are free to do so, even if I still think it is not a good idea.