tests: Measure performance of the SQL cache when it comes to flag access

It is suprisingly slow; one second for 100k items on a memory-backed sqlite DB
on a Sandy Bridge CPU is just shameful. One idea is that the string keys are to
blame here (idea shamelessly stolen from the KDEPIM guys who were recently
hitting a very same problem); other reason might be that the separate SELECTs
hurt a lot. (Hint: #2 is actually true in this case. #1 might be a problem
later.)
tests: make it possible to use LibMailboxSync with a custom cache

Sometimes we care about the performance of a real-world SQL cache.
tests: measure how quickly we can load flags from the cache and resync them

The scenario is as follows: the user has opened the mailbox before, but Trojita
was closed since that time. This means that the flags will be loaded from cache
when the user opens the mailbox next time. The goal here is including the
overhead of reading flags from cache in the resulting number. It takes roughly
3.8 - 3.9s on my T420s.
IMAP: do not overwrite flags with data from cache

There is no point in doing this and wasting CPU resources for something which is
already updated elsewhere. The flags are always maintained by the mailbox
synchronization; this code is just useless.
cache: Read the flags in one sweep instead of repeating it all the time

This commit introduces a new API for accessing the cached flags. Instead of
always looking up each and every flag by hand, we're now using a single sweep
through the table for all messages in a mailbox. This relies on the fact the the
items are already sorted by the UID, so the sqlite's native record stepping
works to our advantage. Unfortunately, it might well happen that the cache can
contain additional extra items (the cache on my laptop certainly does), so
there's still that fallback for accessing each item individually. This might
change in future -- perhaps the data shall be squashed to  just a single row in
the table at the cost of maybe more expensive updates.

I guess I have more measurements to make here.

Some of the tests are now a bit more noisy due to these checks; this is
something to be solved later on.