Fixes #100707 - Since KDE's maintainers don't allow non official kde
applications under the `kdeApplications` path, many packages that depend
on KDE libraries and applications are defined in all-packages.nix.
Overriding all kdeApplications to use qt514 while all other
`libsForQt5.callPackage` in all-packages.nix are using qt515, causes
collisions.

Make sure only compatible qt versions are used for it (#101369) -
kdeFrameworks is always using `libsForQt5` where e.g
`libsForQt514.kpmcore` would have otherwise used a kio compiled with
qt515.

Part of #101369: In order to avoid packages using the default `kdesu`
always built with qt515, we put it in scope only for packages defined
with a `libsForQt5`, to avoid incompatible qt versions used together in
inputs of a package.

Since it's a qt library, we can't guarantee every package using it as a
dependency will need it compiled with the same qt version, we put it in
all `libsForQt5*` scopes (#101369).

Intro:

Part of #101369: Every attribute from kdeApplications and kdeFrameworks
can be built with a few different qt5 versions. It's hard to tell the
difference between an application and a library and some applications
rely on inputs from kdeApplications and libsForQt5 alike.

Before this change, some applications that were defined with
`libsForQt5.callPackage` used libraries from the kde* sets compiled with
a specific qt5 version,

Due to `inherit (kde*) <lib or app>;` used in the widest scope, we had
issues with packages that depended on packages defined by this
`inherit`. This led to mismatched qt versions used in the same inputs,
or the inputs of inputs etc.

Hence, we added to all libsForQt5* sets, packages that will be used from
the correct libsForQt5 set, in accordance to the
`libsForQt5*.callPackage` used. All `inherit (kdeApplications) <pkgs>`
and similar inheritance was moved out of all-packages.nix to aliases.nix
only for backwards compatibility.

Now some KDE applications show up in the attribute sets `libsForQt5*`
which didn't show up there previously. This is sort of misleading, as
these are not necessary libraries, but they show up in the wider scope
thanks to them in aliases.nix. Hence it's the best that can be done
considering the circumstances and the urgency of the issue.

Part of (#101369): kdeApplications points to a set of derivations built
with a specific qt version, where libkcddb is available in libsForQt5's
callPackage scope, thanks to the parent commit of this commit.

Use libsForQt5.callPackage (#101369).

Slightly related to #101369, a follow up to:
4fd58aa

Don't rely on the attribute from the aliases.nix, as ofborg checks that
in PRs.

Since it is used in minuet and kde's metronome and kmetronome, it's
safer this way to make sure the same qt version is used there.

Since it's a dependency of kde's "discover", it's best to define it
there to avoid a possible mixed qt5 versions usage (#101369).

This reverts commit 575b3a0.

We don't know why ttuegel did it, and we suspect it was due to packages
breaking due to mixed qt5 versions used together, and not plasma itself
with qt5.15 - (#101369).

Part of #101369: Inherit it in aliases.nix, for backwards compatibility.

Currently lxqt is a desktop environment that's compiled against qt514.
To avoid possible issues (#101369), we (hopefully) use the same qt
version as the desktop environment at hand. LXQT should move to qt515,
and for the long term the correct qt version should be inherited by the
sddm module.

Use `buildInputs` instead of `propagatedBuildInputs` - should reduce
closure size a bit. Don't wrap executables twice. Move `kdoctools` to
native. Use libsForQt5 - default version (works).

Co-authored-by: Frederik Rietdijk <fridh@fridh.nl>

Use fetchFromGitLab as it seems to be unavailable in the previous url.

cshatag: init at 2019-12-03

kdeApplications: Use latest qt515 by default