This is a slightly modernized version of Pino's original implementation
found in KF5 and Plasma.

We have identical copies of this in kinit, kwin, ksysguard and
powerdevil. This makes it a natural candidate for inclusion in ECM.

It is based on the one that can be found in KWin.

Several KDE projects already use libepoxy (KWin and KDeclarative).

Have the C counterpart take care of the C files and the C++ for the C++
files.
Don't forget to skip the server C implementation.

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.

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.

When creating a library or executable, several source files are combined
into a binary artifact that has an outbound license of its own. This test
generator allows to check if the combined source files are compatible
with the desired outbound license.

Requirements for using these tests:
- input source files must contain the SPDX-License-Information tag
- python3 must be available
- the "reuse spdx" tool must be available