Prefetching can be interrupted by other service requests.

This is the re-merging of ag/12923546 (where most of that original
message is posted below), which includes various bug fixes.

Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.

Let's make it so a user interactive requests stops prefetching.
We can't interrupt an API call, but we can stop in between API calls.

On the service side, we have to separate the prefetch callbacks from the
find callback. And we have to make it asynchronous. It does dispatch
intothe main thread, so the AccessibilityCache can remain single threaded.

When the calls are interrupted on the application side,
returnPendingFindAccessibilityNodeInfosInPrefetch checks the find
requests that are waiting in the queue, to see if they can be addressed
by the prefetch results. If they can be, we don't have to call into
potentially non-performant application code. We don't  check requests
that have differing prefetch flags (FLAG_INCLUDE_NOT_IMPORTANT_VIEWS,
FLAG_REPORT_VIEW_IDS) that would result in different caches.

We also make mPendingFindNodeByIdMessages thread-safe and ensure in
ActionReplacingCallback we don't return null results. Merged
ag/13246536, ag/13256330

UiAutomation does't require a main thread, so getMainLooper may
return null. In this case, instead of posting to the main looper,
we cache nodes on the binder thread (which is our ultimate goal
once b/180957109 is fixed).

Added tests to verify AccessibilityInteractionController interactions

Test: atest AccessibilityInteractionControllerNodeRequestsTest,
FrameworksServicesTests FrameworksCoreTests, CtsAccessibility, Manual
testing

Bug: b/176195360, b/175877007, b/175884343, b/178726546, b/175832139,
b/176195505

Change-Id: I346a3f40c84c6697b8a1e1d84a636eada655b984