KF5 in trunk

[Adriaan de Groot]

Recently, area51 trunk was pretty much declared dead. All the good stuff (tm) 
was happening in plasma5/ branch, largely thanks to tcb. Having qt 5.6 and 
cmake and some other big PRs in-flight didn't help much: trunk was way out of 
sync.

Trunk has been resurrected.

After some rough-and-tumble merges, it caught up with official downstream ports 
recently, and has now had its role restored as the place where "the next big 
thing" is prepared.

Based off of D7645 (which massaged kde.mk and makes USES=kde a lot more 
flexible, again thanks to tcb), trunk has now had KDE Frameworks 5 added. 
That's the tiers 1, 2 and 3 from https://api.kde.org/frameworks/ , with only a 
few exceptions (which can be found in kde.mk).

Current roadmap is this:
 - get D7645 done, so that all the existing kde4 ports use the new mechanics
 - merge that into trunk
 - flush trunk, now with kf5, downstream in another review / PR

This can be done because the kf5 ports are all named consistently and don't 
collide with anything. Now, just having kf5 ports in the tree isn't going to 
buy us any user-visible functionality, but it's good to have that as a 
checkpoint anyway: the supporting libraries.

The map after getting kf5 in has a number of points of interest, but I don't 
know what makes the most sense, order-wise:

 - handle the big name-shuffling to make (name)space for co-existence of KDE4 
and KF5-based applications; there's still the discussion to be had about the 
desirability of keeping KDE4 apps in some kind of legacy form.
 - add plasma5 desktop; this probably doesn't name-collide with anything else, 
and could provide a Plasma 5 desktop experience with KDE4 applications running 
in it (or, of course, anything else X-based),
 - update KDE4 applications to the latest released versions,
 - add KF5-based applications to ports.

[ade]