Detect flag changes during initial sync.

Summary:
In this chapter of the IMAP sync saga, we restructure the Gmail and condstore
sync engines to allow us to detect flag changes during initial sync.

For Gmail, we'd previously run __check_new_g_thrids() in a separate greenlet
during initial sync. However, this wouldn't detect flag changes (marking a
thread as read, etc.). There were also some similar issues for generic IMAP
with condstore.

The key observation is that during initial sync, we should really be doing the
same highestmodseq-updating that we do when polling, in order to fully detect
changes. The only difference is that during initial sync, actual downloading of
messages happens asynchronously on the main greenlet.

This commit replaces the `check_new_uids()`, `__check_new_g_thrids()`,
`__imap_flag_change_poller()`, and `__check_flags()` greenlets by a single
`poll_for_changes()` greenlet, which has one implementation for condstore and
one for non-condstore IMAP sync. This greenlet is responsible for updating
metadata, removing deleted uids, and adding new uids onto the download stack.

Smaller associated changes:
 * Define classes UIDStack and GMessageStack that wrap gevent.LifoQueue, to
   allow for more concise manipulations of the download stacks.
 * Don't track `update_uid_count` or `delete_uid_count` when calling
   update_uid_counts() -- we don't actually use those numbers for anything.
 * Change uidvalidity_cb parameters for simpler invocation.
 * Return the crispin client before sleeping in generic non-condstore poll.
   This was blocking syncs on folders with more accounts than the size
   of the connection pool
 * Actually sync Gmail Inbox most-recent-thread first, and not in arbitrary order.

Fixes T322.

Test Plan: Working on it :/ Suggestions welcome.

Reviewers: khamidou, spang

Reviewed By: spang

Maniphest Tasks: T322

Differential Revision: https://review.inboxapp.com/D433