Offload user-switching task from startInputOrWindowGainedFocus()

As tracked in Bug 28750507, InputMethodManagerService#onSwitchUser()
is known to be slow, and the direct reason of the UI jank in the
launcher discussed Bug 139806621 is that #onSwitchUser() is running as
part of IMMS#startInputOrWindowGainedFocus() that is called as a sync
IPC from the UI thread of the launcher.  Note that this is a
relatively new behavior that was introduced in Android 10 to support
per-profile IME mode (Bug 111083076). So users shouldn't see this code
path unless the device is running on Android 10 with work profile
enabled.

What this CL does is removing that direct code path from
IMMS#startInputOrWindowGainedFocus() to #onSwitchUser() by introducing
a new pending result

  InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING,

which means

  IMMS is now performing user switching and cannot start input session
  right now, but it will call the client back when the IME becomes
  available for the target user.

Note that InputMethodManager is already able to handle this kind of
pending state, where IME is not yet available, since we already have a
similar pending results as follows.

 * InputBindResult.ResultCode.SUCCESS_WAITING_USER_SWITCHING
 * InputBindResult.ResultCode.SUCCESS_WAITING_IME_BINDING

One remaining concern is that when IMMS#switchUserOnHandlerLocked() is
running with holding the giant lock (IMMS#mMethodMap), thus it's still
possible that IMMS#startInputOrWindowGainedFocus() can be blocked
because of lock contention, which eventually blocks client's UI
thread.  Although its chance wouldn't be that high, in order to tackle
that scenario we need to pursue different approaches such as:

 * Further optimize IMMS#startInputOrWindowGainedFocus() to reduce the
   likelihood of lock contention. This isn't a perfect solution for
   this particular case but it's still worth doing.  Possible
   candidate of optimizations are:
    * Bug 28750507:  optimize IMMS#switchUserOnHandlerLocked()
    * Bug 149864769: off-load Context#unbindService()
    * Reconsider the use of giant lock.

 * Redesign the current "startInput" protocol as part of our on-going
   effort to redesign IME focus handling protocol (Bug 141738570)
   e.g. can we completely make IMMS#startInputOrWindowGainedFocus()
   async IPC?

Bug: 139806621
Fix: 144291210
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Manually made sure that IMMS#startInputOrWindowGainedFocus()
      isn't blocking Launcher's UI thread when swiping home.
  1. lunch aosp_coral-userdebug && make -j
  2. Flash the image
  3. Open the system settings
  4. System -> Gestures -> System nagivation
  5. Select "Gesture nagivation"
  6. Install Test DPC.
  7. Enable managed profile with Test DPC.
  8. adb install -r \
        $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
  # deal with dex2oat
  9. adb shell cmd package compile -m speed \
        -f com.google.android.inputmethod.latin
 10. adb shell cmd package compile -m speed \
        -f com.android.inputmethod.tools.edittextvariations
 11. adb shell cmd package compile -m speed \
        -f com.google.android.apps.nexuslauncher
 12. adb root
 13. adb shell setprop pm.dexopt.disable_bg_dexopt true
 14. adb reboot
 15. adb shell am start -u 10 \
        -n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
 16. Tap the first edit text on the EditTextVariations
 17. Make sure that AOSP Keyboard is shown
 18. adb shell am trace-ipc start
 19. external/chromium-trace/systrace.py \
        gfx freq am wm sched binder_driver view \
        -a com.android.launcher3 -o binder.html
 20. Swipe up the home button
 21. Hit the enter key to terminate the systrace.
 22. Check the IPC log to see how much the UI thread is blocked by
     IMMS#startInputOrWindowGainedFocus()
Change-Id: I5a73a66d2b8acadad9b3577ebc4c17b5a25fd011