Change structure inside UnifiedNlp

[mar-v-in]

Currently we have the components

• org.microg:unifiednlp-api: The UnifiedNlp module API
• org.microg:unifiednlp-compat: This is just providing some dummy code for linking to platform internal classes
• org.microg:unifiednlp-base: This is all of the unifiednlp logic for all supported android versions
• org.microg:unifiednlp-app: This is a wrapper around unifiednlp-base to make it a standalone application. It comes in three flavors for specific use cases.

Plan is to create the following component structure:

• org.microg.nlp:api: Same as org.microg:unifiednlp-api
• org.microg.nlp:compat: Same as org.microg:unifiednlp-compat
• org.microg.nlp:service: Version independent service with unifiednlp logic connecting to the modules.
• org.microg.nlp:client: Client library to directly interact with org.microg.nlp:service.
• org.microg.nlp:location-v1, org.microg.nlp:location-v2, org.microg.nlp:location-v3, org.microg.nlp:geocode: Separated implementations of each protocol version of nlp and geocode, each using org.microg.nlp:client
• org.microg.nlp:fused: New implementation of the fused system provider (not the fused gms provider) using org.microg.nlp:client and system gps
• org.microg.nlp:app: With various flavors to include a subset of the previous components (LegacyProxyToGms, LegacyStandalone, NewStandalone, ServiceStandalone)

Rationale:

• Increase stability by having system provider out of UnifiedNlp process
• Don't have to "run" UnifiedNlp twice on legacy devices with gms
• Allow fused gms provider to directly talk to UnifiedNlp service without system intermediary via org.microg.nlp:client

API for modules stays the same, no action needed from module developers.