Make sure at least one IME is enabled.

It turns out that there still exists an edge case where the device can
be fallen into a state where IMMS would pick up no IME at the boot
phase.  Suppose the following case:

  Selecte IMEs  : IME X
  Enabled IMEs  : IME X, IME Y, IME Z
  Available IMEs: IME A, IME B

IMMS has already taken care of the case where the selected IME X is no
longer available at the boot phase for some reasons, which is good, but
what it does in InputMethodManagerService#chooseNewDefaultIMELocked() is
just picking up the best-looking IME only from the "Enabled IMEs"
without considering the case where all the enabled IMEs are unavailable
and we have to enable some IMEs as if it was the first boot.

This issue was found when making IMMS File-Based Encryption (FBE), where
it is relatively easy to see such a situation, e.g. only IME A and IME B
are encryption-aware, but subtle but critical details in storage layer
could cause the same situation.  Bug 6685037 is an example.

As a tentative workaround, this CL introduces a recovery logic in
IMMS#buildInputMethodListLocked() as a workaround.  In future we really
should sort out those initialization code though.

Full FBE support will be added in the next CL [1].

  [1] Ifa2225070bf8223f8964cf063c86889e312c5e9a

Bug: 26279466
Change-Id: Ibd53ef8db7afcfac681b401912876d2a52c743d5