With the switch to binary protocol it's now easier to send over different
kinds of messages, including change notifications. Using the socket and our
straight-forward serialization instead of DBus marshalling and QtDBus type
handling is much faster and more efficient. This should be especially notable
during start when we sync resources and generate lots of uncompressable
notifications. Previously this would hog the DBus daemon, but now we stream
directly from Server to clients. Now it looks like the actual bottleneck are
the applications and their event handling (yay! :)

For now the subscription is still managed via a DBus interface, but eventually
we could switch to using the connection not only to deliver notifications,
but to manage the notification subscription as well.

This change completely removes all Akonadi::NotificationMessage* and replaces
them with Protocol::ChangeNotification (it's Protocol::Command, but the API
is  based on Akonadi::NotificationMessageV3).

When client sends LOGIN command, it can specify that the current session should
be used as Notification bus - in such case NotificationManager will try to match
the Connection object with respective NotificationSource based on the session
and source identifiers. When NotificationSource emits a notification, it is
send to the Connection's socket instead of being emitted on DBus.