feat: Add Maps support

[areteruhiro]

Summary

• Add Maps support for apps patched to use MicroG RE.
• Include the Location services required by Maps.
• Add Mapbox and VTM renderer integrations.
• Use OpenFreeMap when no Mapbox or Stadia API key is configured.

Usage

Apply a GmsCore support patch that redirects Google Play services calls to app.revanced.android.gms. Existing Maps API calls such as MapView, MapFragment, and MapsInitializer will then load the bundled Maps implementation from MicroG RE.

Validation

• :play-services-core:assembleMapboxDefaultDebug
• :play-services-core:assembleMapboxDefaultRelease
• :play-services-core:assembleVtmDefaultDebug
• :play-services-location-core:verifyDefaultReleaseResources
• :play-services-location-core:verifyHuaweiReleaseResources
• Installed the signed Mapbox release build on Android 15

[LisoUseInAIKyrios]

Are there any apps with GmsCore patches to test this with?

[LisoUseInAIKyrios]

We plan to soon release an alternative microG that has all upstream microG features, and leave RE as the minimal variant for YT users and people who don't need the "big mama" microG variant.

This PR adds 86,000(!) lines of code to RE. After we have a full microG release the RE changes here would be redundant and weigh down the otherwise lightweight RE.

The changes here also bring in uncertainty of future maintenance and code auditing

[cyberboh]

Are there any apps with GmsCore patches to test this with?

Maybe Google Photos. Maps broken on it after patched and can not see location after photo got uploaded/backuped

[areteruhiro]

Thank you for the clarification. I understand the concern and agree that keeping MicroG-RE lightweight and maintainable is important.
I tested this implementation with LINE (jp.naver.line.android) using a GmsCore support patch. Without the Maps and Location components, LINE’s location-sharing screen could not initialize or render the map correctly. With the build from this PR, the map and location picker worked successfully, so LINE is one confirmed real-world use case for this implementation.
However, considering your plan to release a full-featured microG variant, I agree that the complete Maps implementation would be more appropriate there than in MicroG-RE. Once the repository or target branch for that variant becomes available, I would be happy to move or rebase this work onto it.
This PR can remain as a tested reference or be closed, depending on your preference. Thank you for reviewing it and explaining the future direction of the project.

[LisoUseInAIKyrios]

We can push this code to a feature branch, and make a one off build that anyone can use if they need it. The built microG.apk won't be in the GitHub release section but will be available as a direct link in a GitHub action, and if a third party dev needs to recommend it they can link to it. And since it'll have the same signing key it'll be a direct upgrade of the regular RE release.

We can leave the branch as-is until we figure out the full microG release.

[mar-v-in]

FYI, There is the user flavor upstream that is generally meant to be used for situations like this, which would answer your maintenance question...