ETM: Fixed crash.

Of course the index is not in the model if we don't show the root collection.
dox fix
protect against replaying notifications on bad data

Remove operations indeed will reference UIDs that no loner exist in the
database. However, it is possible to have notifications saved to disk (e.g.)
by a ChangeRecorder which, on next start, reference UIDs that no longer exist.
In that case, we need to drop the message on the ground otherwise we end up
stuck with a notification that never gets cleared every time the resource
is started.
implement support for relation handling in agents
only dequeue if there is something in the queue
correct signal signature

QObject::receivers doesn't complain if a signal doesn't exist,
unlike QObject::connect (e.g.). the optimizations that rely on
QObject::receivers is therefore more brittle than one might expect.
Revert "Always assume someoneWasListening when we get invalid notification in emityNotification()"

This reverts commit afc24995c526e6f6ee3d231a21ce21bf08fb69d4.

someoneWasListening is essential for the change recorder and simply
setting this to true if no one was listening breaks it (because no one
will call replayNext).

Conflicts:
	akonadi/monitor_p.cpp
Revert "Monitor: handle correctly situation when item no longer exists on server"

This reverts commit 1a576d44171f26d7f14e03bb80398f8534eefcd9.

Empty item list or invalid collection is a valid situation during
removals.
Monitor: Correctly deal with invalid notification (ignore them).

* If we don't fetch items or collections we still have to emit the signal.
* Only clean notification if we tried to emit a signal, but noone listened (otherwise we run into this inefficient codepath a lot)