This matters for libraries in the same repository as the application that
also have an AAR that needs to be integrated, as well as QML plugins. For
this to work we need to consider the build directory as a search prefix,
and produce the exact directory layout there that androiddeployqt expects.

For libraries this is then almost transparent for the application build
system, the only thing that needs to be taken care of manually is putting
the corresponding -android-dependencies.xml file into the right place in
the build dir as well. A macro wrapping that might be an option to
centralize that logic here as well in the future.

For QML plugins this is transparent if you have them set up to work without
installation already anyway, otherwise that setup has to be done for this
to work.

Example: https://invent.kde.org/pim/itinerary/-/merge_requests/28

https://invent.kde.org/frameworks/knotifications/-/merge_requests/12 would
presumably also need this (not tested yet).

I had reuse installed but it wasn't being found. Now it is.

1) remove AlignTrailingComments: true

=> this avoids multiline comment changes if e.g. one longer member/variable is added with comments behind it

2) add AllowShortLambdasOnASingleLine: Empty

=> avoid the uglification of lambdas

When NDK r20+ is used along with Qt5.12, APK generation fails because
of the layout change in newer NDK. This patch introduces a new variable
USE_LLVM, when this is set for older Qt versions, androiddeployqt uses
LLVM's tools.

Besides finding Gradle from QtAndroidExtras and thus avoiding the usual
way of the Android world of distributing that (a copy in your source code),
it provides macros to generate and install Android AARs. Those are needed
for libraries that have a non-trivial Java component on Android, e.g.
needing a manifest fragment or having a dependency on other Java libs.

This file has been copied to a few places meanwhile, so centralizing this
in ECM makes sense.

regex gets slightly adjusted to only run on kde.org urls, the actual
repo name may now contain slash as well since
a) basenames aren't necessarily unique anymore
b) by extension we need to give fetchpo an actually unique repo path so
it can resolve the underlying project and its translations