Revert: "Init of OverlayManagerService on a parallel thread"

This reverts commit 94ab1a66.

Reason for revert: overlays are only available after the overlay manager is
initialized. By *not* threading the initialization, the system defines a strong
guarantee that any system service started after the overlay manager's
constructor has been executed can use RRO. This is analogous to how the package
manager scans for application packages as part of its constructor.

As an example of why we need to establish a point in the boot sequence where
overlays are guaranteed to be available, without this commit it is not possible
to customize the default values of the settings provider, that is, an overlay
defined as follows:

  - AndroidManifest.xml:
    <?xml version="1.0" encoding="utf-8"?>
    <manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.android.providers.settings.overlay" >
        <overlay
            android:targetPackage="com.android.providers.settings"
            android:isStatic="true"
            android:priority="1" />
    </manifest>

  - res/values/values.xml:
    <?xml version="1.0" encoding="utf-8"?>
    <resources>
        <bool name="def_notification_pulse">false</bool>
    </resources>

will not be part of the APK paths obtained from the package manager when
forking what will become the SettingsProvider process. By making sure the
overlay manager is fully initialized before returning from its constructor, we
also make sure that the package manager has an up-to-date list of APK paths
ready for when Zygote will fork and specialize.

Bug: 80150169
Test: install an overlay as outlined above && \
      adb exec-out stop && \
      adb exec-out rm -rf /data/system/users && \
      adb exec-out start && \
      adb exec-out cmd settings get system notification_light_pulse  # expected output is '0'
Change-Id: Ifc93ae95fba293a65ea1d834a64da8077f17def0