eds: avoid blocking event processing

eds: avoid blocking event processing

When there are many incoming D-Bus change notifications, processing of
other D-Bus messages can be delayed considerably. This commit is a
first step towards solving this by caching the change notifications
and processing them with lower priority in a glib idle callback.

Ordering of the changes relative to each other is preserved, so
semantically this is the same as immediate processing.

The worst-case scenario is when contacts get added one-by-one to EDS
address books while folks is running, because then each change
triggers one D-Bus signal. With 2000 contacts and four address books
on a fast laptop, the process hosting folks became unresponsive for
137s. The patch reduced that to 0.1s. The downside is an increase of
total test runtime of 4%.

In the scenario where data is already in EDS when folks starts, the
patch reduced response time from 2.3s to 0.2s.

See https://bugs.freedesktop.org/show_bug.cgi?id=60851#c6 for details.