Repository structure changes

I was considering to do a major change in the structure of the microG repositories. The main reason therefor is that I often have to touch multiple repositories. Other reason is that the submodule/symlink system is causing problems every now and then (with non-unix systems, Android Studio, Kotlin gradle plugin, ...).

So I'd propose the following changes:

• Merge GmsApi, GmsLib and GmsCore repos into a single new repository.
  • With each release form that repository (affecting all three components), upload as much as sensible and possible to maven central and GitHub releases.
• Upload remote-droid-guard library (*), wearable library and unifiednlp-base to maven central and fetch from there during build of play-services-core
• Split play-services-core into smaller modules, that can also be included in third-party apps together with corresponding play-services library from microg, so they can work even on systems that don't have microG installed
  • This also implies more focus on play-services library (aka GmsLib) for better integration in third-party apps.
• Remove Android.mk build scripts from all repositories, as they tend to be incompatible with one or another android build version anyway.
  • Provide alternative repository with prebuilts from releases as well as other stuff required for proper
• Rename repositories to get rid of android_packages_ prefix and alike as repositories are no longer intended to be included with android repo tool.

I think this will eventually make contributions from outsiders easier, but I am happy to hear other opinions on that from current contributors (@ale5000-git, @Nanolx, @Vavun, @voidstarstar, @chris42, @oldosfan, etc). Most of these changes will probably not happen before September given my current schedule.

(*) It's not functional for SafetyNet right now, but I will definitely have a look at it at some point again.

Start by reviewing the remaining checklist items, especially splitting play-services-core into smaller modules and removing Android.mk build scripts. Inspect the current repository layout and build configuration before deciding scope. Done would require an agreed structure, compatible builds, and the proposed release or dependency arrangements, but this issue does not identify specific files or tests.