Reworking CMake Android build

[Fernthedev]

Currently, the QPM ecosystem (and consequentially quest mods and libraries) assume Android is the only target. So if one were to decide to build for x86 Windows, it is currently not intended to be supported regardless if the C++ code is portable.

This reduces flexibility if the quest ecosystem opened up outside of Android, say consoles or PC.

However, there is a bigger issue at hand today with libraries such as flamingo, scotland2 and paperlog. These libraries, as part of phase 4, intend to be the gold standard of the new quest modding era. Part of this goal involves consistent and reproducible testing. This should be accomplished through CI without an ARM Linux device. To do so, we need to open up the current QPM CMake assumptions put in place to reduce friction for builds.

This PR intends to discuss such solutions, which will break existing projects in its current state, as well as document the changes taking place.

There are some ways we could accomplish this, though this will take time to iron out. PaperLog is currently the only project opening up to these experiments:

• CMake Build Presets
  • Desktop target
  • Android target with defines such as platform API
  • QPM generating a user local preset for providing NDK path (which will allow qpm ndk use {version} to return in a much better form)
  • Update flexibility for QPM while retaining the structure for user modification
• Meson builds for desktop
  • Double effort
  • Not enough ecosystem support or resources to warrant the maintenance overhead
• Meson builds for cross platform
  • CLion currently does not support Meson, though it does support compile_commands.json. See here Jetbrains tracker
  • Meson ecosystem
• Rust

Everyone is welcome to take part, please do.

[sc2ad]

Quick 2c on my way home:

The core issue is shipping executables for more target platforms in addition to supporting cross compilation locally. It's not the worst thing ever to replace compile lines with a different target architecture, only for tests, while it is annoying.

I think the worse problem at the moment is that qpm always assumes that the executables built are solely for use on Android and thus does not even consider the notion that non-android binaries should be shared.
That will need to be taken care of in tandem with actually building test code that can run locally while linking to qpm-d libs.