[commhistory-daemon] Remove VoicemailHandler

This class monitored a file created by a closed-source plugin to
contactsd, which was used to indicate changes to the voicemail contact.
We do not have that plugin, and we could certainly find a more elegant
solution than this one for reacting to those changes.
Merge pull request #24 from special/voicemail

Remove VoicemailHandler
WIP Enable debug
WIP Completely disable ut_notificationmanager
[commhistory-daemon] Depend on libcommhistory 1.6.17 for ContactListener API
WIP Link contactcache-qt5 and qtcontacts-sqlite-qt5-extensions

libcommhistory should be patched to use a private class for
ContactListener so this isn't necessary, instead.
[commhistory-daemon] Use ContactListener in NotificationManager

ContactListener handles all the intricate problems related to querying
contacts by phone number and IM address, and watching for changes. It's
much simpler and much less buggy to reuse that, rather than reinventing
it badly.
[commhistory-daemon] Refactor notification handling for clarity and stability

NotificationGroup and PersonalNotification are now real types,
responsible for managing themselves, instead of by-value data types.
NotificationManager now maintains a list of NotificationGroup and
handles contact resolution, creating notifications, and adding and
removing them from groups.

It should now be much easier to follow the logic for an actual
notification or group without worrying about subtle behaviors caused by
storing a bunch of values in a QMultiMap and hoping you call the right
functions to update the right things at the right time.

Serialization to a file for persistence is currently disabled. This is
reimplemented later using metadata in the notification system to avoid
potential problems.
[commhistory-daemon] Use nemo-notifications instead of MNotification

This allows us much better control over the actual presentation of the
notifications, which solves some problems that existed when using
MNotification. In particular:

There is one notification per type for the lockscreen, with no banner
representation, which counts the total per group

Each individual message has its own notification for banners, which
enables proper stacking behavior from the system

Notifications are kept persistently by the system and re-created on
startup from attached metadata, rather than a separate cache file

Banners are never shown when updating existing message notifications