Merge pull request #67 from special/eventmodel-fixes

[libcommhistory] Cleanup for EventModelPrivate and related code
[libcommhistory] Fix GroupModelTest failure

The event sorting behavior was changed in 75d4ea3 to consistently sort
events by endTime (or received time), and this resulted in a change of
behavior for the last event of groups.
Rename EventModel::enableContactChanges to setResolveContacts

The old function is kept for API compatibility, but the behavior may
subtly change in the future.
Add ContactResolver class

ContactResolver resolves contacts matching a list of events, and emits a
signal when all events have been resolved (successfully or not). It's
currently built on ContactListener, but could be made more efficient by
using SeasideCache directly later (e.g by handling results from the
cache instantly, and reducing address comparisons). It is intended to
eventually evolve into an API that can replace the bad ContactListener
API entirely.

ContactResolver maintains a cache of lookups to contact results,
intended to provide a fast path when resolving many events using the
same address (which may not exactly match any of a contact's addresses).
Use ContactResolver when filling EventModel

This does not yet alter the addToModel/update paths, only filling the
model by executing a query.
Set up contact listening on setResolveContacts

Before, this was inconsistently enabled after the query was executed, in
a very bug-prone way. It's cheap to enable on an empty model.
Remove contactCache from EventModelPrivate
Asynchronously resolve contacts for EventModelPrivate::addToModel

To preserve the current API (for now), a synchronous option is offered
that will insert the event immediately regardless of contact resolving,
and update asynchronously if necessary. This is used only by
EventModel::addEvents, and can be removed once that function is made
asynchronous.
Port RecentContactsModel to new event contact resolution
Forbid contact resolving when SyncQuery is enabled

Contact resolution is always asynchronous. It could be implemented to
fill the model synchronously and update contacts afterwards, but it
would be fragile and of little use. Synchronous models should be
discouraged as much as possible, anyway.
Don't emit modelReady until model is populated
WIP Debug and timing for contact stuff

Conflicts:
	src/eventmodel_p.cpp