DBus api stability

[David Kahles]

Hi,

> I'm fine with making some changes to the DBus API. Better now than later.

Another solution (which would also break the api), is to introduce a second
signal "pairingChanged" which is called whenever the pairing state changes.
Therefore we would have two distinct signals.

But this made me think about another issue, which could maybe get cleaned
up now:
The duplication of these signals in org.kde.kdeconnect.daemon and in
org.kde.kdeconnect.device. IHMO we shoud decide who is responsible for 
this:
  - The daemon, who is also responsible for add/remove signals
  - The device, which would also make sense because the pairing/visibility
    state is about the device, and not the daemon
  - Don't do anything about it, for api stability reasons

I would prefer removing the signals from org.kde.kdeconnect.device. What do
you think?

Another issue I wanted to point out, are deprecated signals in
org.kde.kdeconnect.device, but I just found out, that they're already
removed in the sslrefactor branch, so that's not an issue anymore.

> Albert

David