QueryBuilder::setForwardOnly: use ForwardOnly mode for sql query

* less RAM
Akonadi::Server: add a benchmark fetch test for a popolated collection
handler::list: CollectionAttributs values are QByteArray

We should read/write them as QByteArray and not as QString
make Akonadi::Server::Connection to build for 12.04
Preserve local-only flags during MERGE

Some flags are never synced to server (because the server does not
support it for instance), so the resource cannot know about them when
syncing changes in the Item (another flags change, payload change,
whatever) and since ItemSync always crates non-incremental flags merging,
we would lost these local-only flags.

This hack ensures, that during MERGE when we have non-incremental flags
changes, certain local flags ($ATTACHMENT, $WATCHED, $INVITATION, ...)
are preserved.
Reduced notification compression.

This are three squashed commits:

Remove notification compression algorithm

The compression does not have much sense nowadays, as we rarely end up in
situation where merging notifications would result in performance improvement
(mostly because the most intensive operations now use batch notifications).
The only actual remaining use for the compression algorithm is in case of removal:

If there is a notification in the queue for a certain Item, and a removal
notification for the same Item is appended to the queue, it means that the Item
no longer exists in Akonadi and at time the first notification is delivered to
Monitor, EntityCache will no longer be able to retrieve the Item, which renders
the notification useless and we need to remove it to prevent EntityCache from
getting Item/CollectionFetchJob error.

However when massive removal operation takes place (in case of Collections that
is, removal of Items is again delivered as Batch notification), the queue has
to be iterated over and over again - and as the queue grows, the algorithm
stops being an optimization and instead becomes a bottleneck.

For that reason we dicided to remove the compression algorithm completely and
instead make sure, that Monitor (and EntityCache) on the client side can
properly handle the case of Item/Collection no longer existing in Akonadi at
the time the Notification is delivered.

Bring back notification compression - at lest partially

Turned out that adding a new Collection generates one ADD and several
(usually 3 in my case) MODIFY notifications - since the MODIFY is
expensive and slows down initial sync, we compress it ito one notification again.

All other notifications are dispatched directly without any compression.

Notification compression: further optimization to minimalize worst-case scenarios

We are now iterating over the list of pending notifications in reverse order,
because it's more probably that compressable notifications are at the end of
the queue rather at the beginning.

Iterating from the end also means that once we reach Add notification for the
same collection, we can break immediatelly and don't have to iterate through the
rest of the list, since there can be no other notifications for this Collection
before "Add"
NotificationCompression: Limit search to last 10 items, and remove modify after add.

Removing the modify after add avoids that each collection is initially indexed twice.
CollectionScheduler: only try to schedule enabled or referenced collections in initScheduler()

Otherwise we end up iterating over a growing QMap of already-scheduled collections
over and over again, which causes Akonadi server to take ages before it starts.
Don't dispatch notifications about disabled collections

The only exception are exclusive subscribers, which expect even notifications
about disabled collections.

For this we add a little hack: a flag that is set by NotificationCollector to
the NotificationMessage that says that the collection in this notification is
disabled. NotificationCollector knows, because it is passed the actual Collection
from caller. The presence of the flag is then evaluated by NotificationSource
when deciding whether to accept the notification or not. This is because
NotificationSource only works with what's in the notification, and querying
database for each Collection to check, whether it's enabled or not would be
very expensive.

When Collection is disabled, the notification is dropped, unless the current
subscriber is exclusive or is monitoring the Collection explicitly, or the
Collection is referenced.
NotificationSource: Make it possible to setExclusive
NotificationSource: Don't drop unsubscribe or enabled notifications

Since the collection is already disabled we require an exception for this.
Otherwise the monitortest doesn't pass.
Made linkhandlertest pass.

RID operations are broken, but we don't currently need them.
Since we removed the notification compression, we also can't test it any longer.
resolveTags: support empty set of tags

We need this to clear tags.
Avoid trying to set negative timer intervals.
ImapStreamParser: Properly parse empty sequence sets.

It used to insert -1. We require this to clear tags using an empty set.
Disabled the imapparser benchmark.

It takes forever and tells us nothing without values to compare to.