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
      fa1886fe

Bug: 31247871
Bug: 31273203
Change-Id: I26479e7aa306e0df91d9911891d5625dd5f99678