[commhistory-daemon] Add LastDialedCache as a hack for Bluetooth

Bluetooth requires the last dialed number from the call log, but for
various reasons can't access commhistory or dbus directly. As a hack,
write the last dialed number from the call log into a file at
$HOME/.cache/last-dialed and keep it updated even when items are removed
from the call log, or the log is cleared.
Merge pull request #25 from special/lastdialed

[commhistory-daemon] Add LastDialedCache as a hack for Bluetooth
[commhistory-daemon] Use SortByTime for LastDialedCache

SortByContact was previously necessary because of bugs in the ungrouped
model, but libcommhistory has been updated to solve that. SortByTime
properly filters and avoids cases where incoming calls wouldn't be
filtered by the model.
Merge pull request #27 from special/lastdialed2

[commhistory-daemon] Use SortByTime for LastDialedCache
[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.

Adds a dependency on libcommhistory 1.6.17 for the updated
ContactListener API.
[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
[commhistory-daemon] Add a very simple new notificationmanager test

It isn't worth trying to port and fix the old, broken test, and writing
a full and comprehensive test requires some external work in
libcommhistory and testing contacts.