Parser: speed up atom parsing

This patch cuts the time spent in getAtom from 7.34% of the total runtime to
4.47%, as measured by the testFlagReSyncBenchmark (valgrind, clang 3.3). This
speed up is obtained by ignoring the high-level API of QByteArray and working on
raw char * instead.

REVIEW: 113118
Use pre-created instances when comparing flag names

The goal here was to elliminate in-place construction of QString instances only
to be destroyed later on when they go out of scope. This change cuts the time
spent in the isMarkedAsRead when running the testFlagReSyncBenchmark test from
2.69% of the total runtime down to 0.57% (clang 3.3). It might be interesting to
see how forcing the comparison to *always* hapen *only* on QString::d would end
up :), but it's rather tricky because that's a private member, of course. That
said, soemthing along the lines of [1] (inspired by [2] which is inspired by
[3]) *might* actually work here.

Tests which attempted to use std::binary_search ended up rather poorly; it seems
that clang 3.3 was not happy enough to inilne the various std::advance and
iterator_traits calls.

[1] https://gist.github.com/dabrahams/1528856
[2] http://bloglitb.blogspot.cz/2010/07/access-to-private-members-thats-easy.html
[3] http://stackoverflow.com/a/3173080/2245623

REVIEW: 113120
Assume that UID, FLAGS and MODSEQ are more common than other FETCH responses and move the comparison earlier

The code which handles the FETCH responses is scanning the passed data in order.
For each item in there, the code has to take a look at what "type of item" it
is, e.g. whether it's an UID, FLAGS, BODYSTRUCTURE or something else. This
jumping is currently performed linearly.

Some items are more frequent than the others. For example, almost every FETCH
response (save the unsolicited ones) contains the UID, so it makes sense to
check for that at first, and carry on in the order of how often these items are
expected to appear. On older IMAP servers, we're syncing FLAGS for the whole
mailbox all the time, so it makes sense to have FLAGS as the second option. The
modern servers are likely to return a MODSEQ with every FLAGS update (which are
less common, though), so it probably doesn't hurt to move these a bit up.

Using GCC 4.6.3 with -O3, the time spent in TreeItemMailbox::handleFetchResponse
is reduced from 12.63% to 11.79% of the total runtime.

REVIEW: 113121
Do not call QByteArray::toUpper when parsing NILs

The previous form of case-insensitive comparisons involved calls to
QChar::toUpper() which are pretty expensive. This patch cuts the time spent in
Responses::Fetch::Fetch from 34.38% down to 30.69% of the runtime using my
favorite benchmark. Callgrind reports that the cycle estimate is reduced from
14.32 millions down to 13.44 millions for the whole testFlagReSyncBenchmark
test.
Refactoring: move the atom-specials recognition out
Fix parsing to not recognize NILxxx as NIL

There was a long-standing bug in the parser which apparently treated any atoms
starting with NIL as NILs. The good thing about that was that it only happened
when the data were not transmitted as quoted strings or literals *and* the code
asked for the token via getAnything. It's still a pretty severe bug, though,
which could lead to stuff not showing up in Trojita for some reason.
Simplify the getNString's code
Merge branch 'atom-parsing-speedup'

REVIEW: 113140
IMAP: detect UIDVALIDITY changes when they happen while a mailbox is already selected

No real-world IMAP server shall do this, ever, and expect the clients to work
well. That said, clients absolutely have to handle this reasonably. Given that
no server is known to do this (apart from an old version which does this at most
once for a user for reasons related to delayed mailbox allocation), it seems
acceptable to simply disconnect in this case.

Yes, it might be possible to reconnect to the mailbox. However, verifying that
all pending requests are killed reasonably is too much work for a condition that
no Trojita user will ever see, hopefully.

BUG: 324763
REVIEW: 113109