Move 3 IMMS utility classes to services.jar

Short summary:

There is no need to have these 3 utility classes in frameworks.jar,
because these classes are used only from InputMethodManagerService
(IMMS) and its utility classes. We should move them to services.jar.

Long summary:

 * InputMethodSubtypeSwitchingController

This class was mistakenly placed in the current Java package since its
beginning [1].  This class is purely a state machine that is designed
to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.

 * LocaleUtils

This class was also mistakenly placed in the current Java package
since its beginning [2].  This class is purely a state machine that is
designed to be used only from IMMS hence there has been no way for app
processes to use this class in a meaningful way.

 * InputMethodUtils

The situation of InputMethodUtils is a bit different.  It was
introduced in the right place actually [3], because the original
purpose of this class was to share some utility methods between IMMS
and the Settings application.  For that purpose, having this class
under frameworks/base/core/java instead of frameworks/base/services/
totally made sense.

What was unfortunate is that we have kept adding more and more utility
methods into InputMethodUtils since then, even though most of methods
have been used only from IMMS.  To make things worse, more and more
random components started depending on this utility class.  When we
realized it, we were in the situation where we could not even easily
refactor methods in InputMethodUtils without updating a bunch of
call-sites across repositories, including multiple platform-specific
Settings app and SetupWizards.

This is basically why I decided to stop allowing Settings apps and
SetupWizard to use InputMethodUtils, and decided to let them depend on
SettingsLib [4] instead.  After many cleanup CLs [5], we have finally
achieved the state where InputMethodUtils is used only from the system
server process.

 * A special bonus

With my previous CL [6], we can even make these 3 utility classes
package-private, which guarantees that only IMMS and its utility
classes directly depends on these utility classes.

 * Risk

Now that this is purely a mechanical refactoring of an implementation
detail within frameworks/base, there should be no observable behavior
difference.

 [1]: I11ed9a767588f8080753cd9bce011dac7db579ad
      d7443c83
 [2]: I315cf3722a06e00bdbfac284c4949578da8fe78d
      102ff072
 [3]: I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6
      8e303cc5
 [4]: frameworks/base/packages/SettingsLib
 [5]: CLs that have Bug 77730201 in their commit messages
 [6]: I023d8f2863601ee54f304988117d8ea750770f70
      603f4d00

Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.inputmethod
Change-Id: I37594096151d77adb6741a41d7985a4506f96ccb