It's extremely rare that a filler would have 0 children. If it claims
to have 0, that suggests the app/toolkit is failing to emit children-
changed:add events. Clearing the cache can sometimes work around this
problem, but it is not 100% reliable and can require multiple attempts.

Normally when a user copies and pastes a file/folder in a file manager,
we get a selection-changed event from the container of the just-pasted
item and want to update our location. But when copying and pasting a
large number of items in Caja, we are placed in a new window for the
progress and eventually get the aforementioned selection-changed event.
Therefore, be sure the container is in the active window before updating
our location.

If an object is in the process of being destroyed, getting its
character count (without exception handling) can cause Orca to spit
up. While we could of course add that exception handling, the lack
of text content shouldn't cause us to deem an element not texty; it
is simply an empty text element. Therefore remove that character-
count check entirely.

When the locusOfFocus is being destroyed, the event.any_data from the
children-removed event sometimes contains an already-dead accessible
object. We were ignoring these events on the grounds that there wasn't
much to do other than wait for an event (e.g. focused) for the new
location. But scripts which cache objects (e.g. web) might be able
to do some cleanup, so allow that to happen by not ignoring these
events.

* Preserve context when dumping cache children-changed:add
* Dump cache (but preserve context) in children-changed:removed
* Search for caret context in parent when line nav isn't being used

Apps like Caja seem to like to flood us with active-descendant-changed
and selection-changed events. We are already ignoring the former based
on the supposed new active descendant being defunct. We were also
trying to catch this condition and ignore the selection-changed flood,
but were returning early when the active-descendant was already dead.
Its death short-circuited the remaining logic. Therefore, don't return
quite so early for dead descendants so that we can add the spammy
offender to the list of objects destroying children.

More spam.

Certain chat web apps have an editable text object with descendant
elements. If one gives it focus with tab, we should just present the
entry rather than the full bar.

The previous commit ensured we spoke just the newly-focused editable
object when Tab was pressed. But the object could be autofocused by
the app, or given focus by mouse click. Therefore only generate the
full line for newly-focused editable objects when Orca's caret nav
or structural nav was used to move into them.

Also add more debugging to hunt down weird problem.

Sometimes we get a single event for a child removal, but the child
being removed is potentially an ancestor of the locusOfFocus. Or
there may be a case where the equality check between the removed child
and the locusOfFocus fails. Therefore if the locusOfFocus is dead,
allow scripts to handle this event so they can do any possibly clean
up / recovery.

If an object has been destroyed, and is inside a giant subtree of
just-destroyed elements, we will spend a potentially very long
time trying to find contents, and in the end still fail. So bail
immediately if the object is dead.

It appears that sometimes we're getting the status bar itself as part
of the status bar's items (or perhaps the status bar has a descendant
status bar??). This can lead to infinite recursion. Therefore, filter
out any status bars returned when we get the status bar's items. Also
add a redundant check to the speech generator to ensure we avoid this
problem.

If an accessible object claims to be its own parent, topLevelObject
will never return.