Refactoring of the DBus Interface

Our current DBus interface exposes all signals, slots and properties of
both MarbleWidget and MarbleMap to the DBus session bus. There are a
couple of problems:
- 3rd party developers who include MarbleWidget have their application
  exposed to DBus and the Marble part of it can be controlled from
  there.
- not all method signatures are compatible with DBus. In particular
  QRegion and Marble specific types cannot be send over DBus (without
  us implementing support for it). In Qt5 there seems to be a change
  that warns against that in the shell. This means that in Qt5 you get
  lots of debug spam all the time in the shell, e.g. a simple map drag
  results in hundreds of warnings a la
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleMap::renderStateChanged(RenderState): Unregistered input
type in parameter list: RenderState
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleWidget::mouseClickGeoPosition(double,double,GeoDataCoordin
ates::Unit): Unregistered input type in parameter list:
GeoDataCoordinates::Unit
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleMap::repaintNeeded(QRegion): Type not registered with
QtDBus in parameter list: QRegion
- it's an utter mess. Currently we expose more than 120 (!) Marble
  specific things to DBus

The patch tries to improve that by
- Not exposing anything to DBus in the library, but only from the Qt
  and KDE applications (i.e. move session bus registration to
  ControlView.cpp)
- Expose only a limited subset of methods and properties (implemented
  in the new class MarbleDBusInterface)

The drawbacks are that we're changing the interface (hence break any
external scripts etc. that rely on it), and limit it at the same time
-- some information that people might be using is not available
anymore. I'm not aware of anyone really using the DBus interface
though, so I'd risk changing it. For limited functionality I'm happy to
bring in more things if there's a sane use case behind it.

REVIEW: 123896