Fix another deadlock between IMMS and TSMS

Fix another deadlock between IMMS and TSMS

Bug 31247871 and Bug 31273203 are the same in terms of that both can be
triggered by calling TSM##getCurrentSpellCheckerSubtype() but different
in terms of what lock objects are involved.

To summarize

 Bug 31273203: between IMMS#mMethodMap and IMM#H
  A. OnClickListener.onClick() running in the IMMS locks IMMS#mMethodMap
     then does some View operations, which can be blocked until
     IMM#H is unlocked (e.g. IMM#onViewDetachedFromWindow()).
  B. TSMS#getCurrentSpellCheckerSubtype() internally calls
     IMM#getCurrentInputMethodSubtype(), which locks IMM#H then can be
     blocked until IMMS#mMethodMap is unlocked.
  The tricky point here is that IMMS and TSMS are running in the same
  process hence IMM#H are actually shared between them.

 Bug 31247871: between IMMS#mMethodMap and TSMS#mSpellCheckerMap
  C. IMMS locks IMMS#mMethodMap then calls
     InputMethodUtils#setNonSelectedSystemImesDisabledUntilUsed(), which
     can be blocked until TSMS#mSpellCheckerMap is unlocked.
  D. TSMS#getCurrentSpellCheckerSubtype() locks TSMS#mSpellCheckerMap
     then may call IMM#getCurrentInputMethodSubtype(), which can be
     blocked until IMMS#mMethodMap is released.

This CL aims to remove the layered lock in D to close Bug 31247871,
while the previous CL [1] took care of B to close Bug 31273203.

Note that A and C are still concerning and should also be taken care of
as a part of Bug 31273203.

 [1]: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
      fa1886feea55785f413f5efcd86bccca92f26759

Bug: 31247871
Bug: 31273203
Change-Id: I26479e7aa306e0df91d9911891d5625dd5f99678