Update foreground service with service type for API 34+

[05nelsonm]

Android API 34+ now requires Foreground Services to declare a type, and then declare the requested permission in the manifest.

This update should be done for branches:

• [ ] master
• [ ] 1.x.x.

See https://developer.android.com/about/versions/14/changes/fgs-types-required

Will need to take the same approach as with FOREGROUND_SERVICE permissions missing from manifest and set enableForeground to false, otherwise starting the service will fail.

[05nelsonm]

Branch 1.x.x does not need to be updated as it can be solved locally via manifest merge if they are utilizing it as a foreground service. The update would require consumers to add the permission anyway, so instead of choosing what type to declare and the corresponding permission, they can do it. This way people who are not utilizing the 1.x.x service as a Foreground Service are unaffected by the manifest declaration they would inherit from this library.

kmp-tor 1.x.x foreground service users API 34+ fix using FOREGROUND_SERVICE_SPECIAL_USE (or w/e type they desire)

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <!-- API 34+ https://developer.android.com/about/versions/14/changes/fgs-types-required#special-use -->
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE" />

    <application>
        <service
            android:name="io.matthewnelson.kmp.tor.manager.internal.TorService"
            android:enabled="true"
            android:exported="false"
            android:foregroundServiceType="specialUse"
            tools:node="merge">

            <!-- Only needed if using type specialUse, as described in docs above. -->
            <property
                android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
                android:value="TODO" />
        </service>
    </application>

</manifest>

[05nelsonm]

Solution for 2.0.0 is to have a separate -ui module and inject an adapter at runtime which will handle rendering the state. This provides some awesome benefits.

1. Allows people the ability to have custom implementations and configure their own Foreground Service notification
2. They can go with the default UI from the -ui module.
3. No more <meta-data> tags needed, as everything will be configurable from code.

This also means that an adapter can be created for SavedState restoration as another optional thing.

[05nelsonm]

Closing this. Consumers should handle it in their manifests as depicted above. I am unwilling to request a certain permission for someone else, as it may have an effect on their app store review. They can merge their choice. It does however need to be documented still which will be done once the UI layer re-work is completed.