support for proper label reading with relationships and the selection events

[albertotirla]

the issue #124 is also relevant here, so mentioning just in case

Essentially, desktop and popup menus don't currently read, neither do list items.

I propose we implement the selection events, including the state changed event where the new state is selected, in order to try to fix the menus issue we currently have. This should behave relatively like the focused event handler we already have, just with another event kind. By that, I mean, it should say the name or label of that control, the control role, etc, information the user would usually expect

We should also try to implement reading of labels properly, using the relationships set, because now we only use the name and description of objects, while doing nothing if those are empty, even though we didn't exhaust all paths before giving up. While that could be alright in some cases, the cases where it's not are significant and keep increasing. It's a relatively small change all things considered, so then implementation is relatively easy:

• for each accessible we're about to report information on, doesn't matter from what event it came,
• check for the extended relationships method, the one that returns something like Hashmap<RelationshipType, Vec<AccessibleProxy<_>>>, if I'm not entirely mistaken
• find the RelationshipType::LabeledBy key
• for each entry in the list, concat the names or text
• return that result as the label for the control