Reenable CursorAnchorInfo API with ActivityView

With my previous CL [1], CursorAnchorInfo API was globally disabled
for cross-display scenario including ActivityView scenario.

This CL slightly relaxes the above condition so that IMEs can rely on
CursorAnchorInfo APIs again to interact with apps running inside
ActivityView.

The basic idea here is keeping reporting relevant information from
ActivityView to InputMethodManagerService (IMMS) so that IMMS can take
the display hierarchy because of ActivityView into account.  As long
as IMMS has the up-to-date hierarchical information, IMMS can tell
InputMethodManager (IMM) running in the IME client process about the
missing coordinate transformation information from the virtual display
space to the outer display space where the IME is actually shown.

Note that there was a similar fix for AccessibilityService that keeps
reporting ActivityView location to WindowManagerService (WMS) [2].
Ideally we should be able to share the logic, but to do so we need to
introduce a generalized callback mechanism into WMS so that IMMS can
be notified when a cetain coordinate transform matrix has changed.
For Q, this CL implements IMMS's own mechanism to keep track of
ActivityView hierarchy instead of introducing a direct dependency from
WMS to IMMS.

For R+, most likely we may want to reconsider how ActivityView should
be implemented.

There should be no behavior change in this CL if ActivityView is not
involved.

 [1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
      3d2cc0ff
 [2]: I38da5b84a11890bf0f4a57eb9d5b7e71bdcc16a9
      d8ec9386

Fix: 115693908
Test: atest CtsWindowManagerDeviceTestCases:ActivityViewTest#testInputMethod
Change-Id: Id0411a80456182111bb5b681c6d1230b58e7ec2e