Let InputMethodPrivilegedOperationsRegistry deal with its singleton-ness

This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.

When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.

Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs.  Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.

With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.

 * InputMethodManager.hideSoftInputFromInputMethod
 * InputMethodManager.hideStatusIcon
 * InputMethodManager.setInputMethod
 * InputMethodManager.setInputMethodAndSubtype
 * InputMethodManager.shouldOfferSwitchingToNextInputMethod
 * InputMethodManager.showSoftInputFromInputMethod
 * InputMethodManager.showStatusIcon
 * InputMethodManager.switchToLastInputMethod
 * InputMethodManager.switchToNextInputMethod

 [1]: If762714b2003fa6477e1318110f63e13968c1d7e
      eec552e9e9c453a7921463e5a0ade959e030f9a0

Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4

0 files changed, 0 insertions, 0 deletions