Initialize MotionClassifier from a separate thread

We are currently calling getService directly from the thread that calls
InputManager constructor. That means, the function call directly affects
the start-up time of the system.
But InputClassifier HAL is not mission-critical, and the system can
function perfectly fine without it. Moreover, we are already allowing
for mMotionClassifier to be null in our code.

In this change, mMotionClassifier will become non-null right away, but
may not be initialized when it is first created. The initialization will
happen in a separate thread. Once initialized, MotionClassifier may
become null inside InputClassifier if the latter receives a HAL death
callback.

To account for the possibility of the MotionClassifier not being valid
right away, we are allowing mService variable in the MotionClassifier to
be nullable.

The contract for mService is as follows: mService is null by default. If
MotionClassifier initializes successfully (may take ~ 100 ms), then
mService will become non-null. Once non-null, it stays non-null.
This allows MotionClassifier's separate thread to not have to check the
nullness of mService.
Other threads, however, must assume that mService can be null. They are
checking the value with a lock held.

If MotionClassifier init fails, it will also call the deathRecipient's
serviceDied call, to signal that it is no longer useful. This should
prompt the owner of MotionClassifier to dispose it.

Bug: 130184032
Test: atest google/perf/boottime/boottime-test
Test: atest libinput_tests inputflinger_tests
Change-Id: Id4f9c316ef6725d96abebc55a96079946647eb39