Try to recover from UIDNEXT mismatch.

In case the IMAP resource ends up with an mismatch in current and last seen
UIDNEXT values, it tries to recover from that with a full re-download. With
online IMAP that's not too bad, but for the offline case this can be a huge
problem. This patch tries to do the recovery in a less drastic way, given
some conditions are met.

The assumption is that this case can happen because of an equal amount of
emails being added and deleted while we were not looking. Then the message
count check passes (we still have the same amount locally and remotely),
but the UIDNEXT check fails. Given UIDs are strictly ascending, the
maximum amount of changed messages is (newUidnext - oldUidnext). So,
instead of downloading everything, we now only download that many messages,
since download is done by sequence number, we are guaranteed to get the
newest ones and thus we cover all new messages. Deletion of the old ones is
done by the subsequent flag fetch step, just as in the normal case.

Thiago's problem shown in bug 259151 is slightly different, there we do the
same modification locally and remotely but fail to obtain the new UID due
to the server not supporting UIDPLUS and the message-id being non-unique.
However, this should work with the above approach as well.

BUG: 259151
REVIEW: 101142