Installing qml caches

[Elv1313 .]

> It might indeed not be useful for distros, but it looks like an interesting
> option to reduce the package size

I played with this last year at Randa after we spoke about it. I
heavily patched everything to bring the size down and improve startup
time. QML cache doesn't help that goal at all. I ended up not using it
and it made both size and startup time worst on mobile devices. The
startup time is I/O bound on modern phones, not CPU bound. I am
leaving for the airport so I can't write a 10 page tutorial and it
isn't related to shipping QML cache.

## What doesn't help:

* Compile QML (it does nothing)
* Minify QML (the bundle are often already compressed)

## What help, but is broken

* Using musl libc because libGl cannot be bundled and they must have
the same libc
* Static glibc causes 2 instances of static vars to exist and it crashes

## What is lost

* The way many KF5 apps use plugins can't work in static modes (like
Kio, kded5, kdeinit5) and have to be patched out.

## What helps:

* Using static libraries
* Using full bundle LTO (link time optimization) (reduces the bundle
size by 75%+ with this alone)
* Enable PGO/FDO (massive improvment in statup time)
* Optimize all SVG for loading speed (reduce the Inkscape created ones
by 96% and Qt loads them faster)
* QRC *everything* to avoid all syscalls and blocking I/O `stat()`
* Create a custom qplatform with more aggressive CXXFLAGS and LDFLAGS
* Using Qt-lite
* Using Gentoo "USE" system to disable optional dependency features
instead of using what ships with Qt
* Stripping the fonts from all the colored icons madness they recently
added and QRC it.

Here's an AppImage produced with the patched frameworks:

http://lvindustries.net:8080/

In both case it is not fully minified. The 45mb ones lack -Os and have
debug symbols.
The 18mb ones are not fully stripped to get useful backtraces. I can
make them ~13mb if I want, but it makes debugging impossible. To have
a good comparaison, that software has mostly the same dependencies as
KDenLive and their AppImage is more than an order of magnitude bigger.
Note that I don't run the PGO/FDO on those builds as I havn't
automated that part yet.

If there is enough interest, I guess I can create a small BoF at
Akademy to demonstrate and talk about how willing we are to makes this
work. If we get serious about this, a lot of things have to change and
new library guidelines enforced. Some people will find the new
limitations imposed on them very frustrating. But the bright side is
85%+ smaller APK/FlatPak/AppImage/DMG/Snap that load multiple time
faster.

(related: https://phabricator.kde.org/D13816)