Because GTK4 lists seem to be used everywhere, and can contain multiple
descendants which app developers expect Orca to present automatically,
Orca v47 and later now looks for and speaks descendants with presentable
information.

Unfortunately, there are apps who decided to address this need themselves
prior to Orca v47, by cramming all the info into the accessible name of
the list item. As a result Orca v47 and later are sometimes super chatty
because Orca presents the name and all the descendants which have something
presentable.

In an attempt to maintain reasonable presentation of both types of app
implementations, make the following changes when generating descendant
presentation:

1. If the item lacks a name, fall back on the labelled-by text.
   There's not a real-word case of this yet. But it's consistent
   with the next item.
2. If the item lacks a description, fall back on the described-by text.
   It doesn't appear that described-by text is automatically exposed
   as the description.
3. When determining if a label's name is redundant to the object name,
   use the string-redundancy check. This is needed because some app
   developers are not using the exact descendant name in the item name.
   A little bit of string massaging is enough to make the existing
   filtering which landed in Orca v47 fail.
4. When determining if a label's name is redundant to the object
   description, also use the string-redundancy check for the same
   reason.
5. If the label's name is redundant to the item description, don't filter
   it out as the descendant; instead don't present the description of the
   object. Example: In Tuba, the toot being exposed as the description
   means Orca will present everything else about the item with the toot
   being last. Instead we want to present the toot in the correct location
   with respect to the other descendants, namely above the status buttons.
6. If the full name of a button is completely contained within the ancestor
   item name, don't present that button. This was also Tuba inspired (the
   status buttons at the end have just a number as their name, and those
   numbers are summarized in the name).

Note: Excluding an item like a button (or anything else) during the
presentation of the item name has nothing to do with presenting that
item when it gains focus (e.g. via Tab within the item).

Fractal exposes two accessible separators surrounding the date label.
Saying "separator" before and after the date is unneeded chattiness.

After the Writer/Calc window becomes active, the current object in the
document claims focus (good). But immediately after an ancestor root pane
claims focus even though the user is still in the document object. There
does not seem to be any reason to present this focus change. It's just
unnecessary chattiness. Furthermore, it is sometimes causing speech to
be interrupted before the real focus is fully announced.

In versions of Calc where the bug is fixed, we get the desired focus
change for the table (yay!). But the on_active_descendant_changed
workaround kicks in if the table firing the event is not an ancestor
of the current focus. In the fixed version of Calc, the table firing
the event is the current focus, so now we're presenting the sheet
twice.

Fix this by adjusting the workaround to not kick in if the table is
the focus. This prevents double-presentation in fixed versions while
keeping the logic in placed for older versions.

5e573ec9 and 153b2553 were needed to ensure we presented the newly-focused
sheet and did so only once when the Calc window was activated. But the sheet
was no longer being presented when the sheet was changed. This was because
a heuristic to detect post-editing focus claims was kicking in and updating
focus silently.

Fix that by adjusting the heuristic to check that the table claiming focus
is an ancestor of the current focus. If it's not, we're likely changing
sheets. This fix alone, however, causes the frame to be announced in
addition to the sheet. So set the locus of focus to the parent of the
table silently prior to the default script handling the focus change.

We normally attempt to calculate an accurate posinset and setsize for
items in a collection when those values have not been provided to us,
e.g. via aria-posinset and aria-setsize (or the native app equivalent).
But before we do that work, we check check the member-of relation, the
node-parent-of relation, do some special handling for description lists,
tables, menus, etc. In the end, however,  we sometimes wind up iterating
through all of the children to determine the membership.

This iteration is no big deal until the set size gets large (say, over 1000
members) at which point we become laggy. Given a set size in the tens of
thousands, we grind to a halt. To see this halt in action, create a folder
with 10,000 items and then use a file explorer to navigate among the items.

In order to be performant, if the parent container has more than 500
children, return its child count as the set size and the item's index
in parent as the position in set. In cases where this result is not
accurate, the app in question should expose the correct position in set
via the "posinset" object attribute on the item and the set size as the
"setsize" object attribute on the same item.

Based on some debugging output from a user. Some (unreleased?) version
of Dolphin does the following each time selection changes:

1. Fires the focused-changed event for the newly-selected item causing
   Orca to announce that item's name and description.
2. Fires a description-changed event for the list, with the description
   being set to the name + the description of the item we just announced.

Starting with Orca v47, Orca presents description changes not only on
the focused object but on its ancestors. This makes it possible for app
developers to associate a description with a group of widgets and update
that description as needed. Unfortunately, it means that we now double-
speak every selected item in whatever version of dolphin has this change.

In order to try to filter this sort of thing out, apply the string
redundancy check comparing the ancestor description to the combined name
plus description of the current focus. If they are simmilar enough, do
not announce the description change.

See issue #542.

The purpose of 1393f174 was to filter out description changes which are
redundant to the focused object coming from some other object (e.g. the
ancestor). But focus_string was being set using obj rather than focus
due to not enough coffee. Correct that here.

See issue #542.

As described in https://bugzilla.mozilla.org/show_bug.cgi?id=1895857,
Orca is super chatty when presenting certain alerts when aria-labelledby
and aria-describedby are used and the label/description point to objects
in the alert. We should add filtering to getObjectContentsAtOffset() for
this condition. However, an ARIA alert should be presented as UI; not
as a text container whose contents should be pieced together. Deferring
to the default script's presentObject() accomplishes this and eliminates
the chattiness.

Two table cells should never be treated as being in the same word,
regardless of position, lack of whitespace, etc.

For all ARIA roles with the expected mapping of PANEL, GTK4 instead gives
us GROUPING. This is not a problem in Orca v48 where there is already
logic that explicitly handles the GROUPING role. However, backporting the
necessary logic in v47 is a bigger change than I would like to make for a
stable version. Therefore, modify AXObject.get_role() to return a PANEL
instead of GROUPING.

See issue #546.

The speech generator now provides the list item count.

See issue #549.

InputEvent sets it to a string; not an int.

Fixes issue #550.

GTK4 exposes "<VoidSymbol>" for widgets which have actions but no binding.
This presentation is less helpful than saying nothing.