Implement a uid/thread-polling helper for IMAP/Gmail initial sync.

Summary:
In the case that a user has e.g. a very large inbox, our current design has the
shortcoming that, during the initial sync, it won't continue to download new
messages. This is untenable for the user experience, so we're solving it by
having a parallel greenlet during this time that keeps checking for new
UIDs/threads and adding them to the top of the initial sync uid/thread download
stack.

By doing this, we have to get rid of the "chunked download" feature...  if we
batch download messages in groups, we'll introduce a delay with how fast we
download new UIDs. It's not clear to me that batching actually wins us that
much speed anyway.

I think we're going to need to introduce IDLE support at some point for
the quickest receipt of new mail, but this is better than what we've got
for now.

Test Plan: ./runtests + a bunch of manual testing that has me thinking real hard about how to do better automatic testing.

Reviewers: mg

CC: kav-ya

Differential Revision: https://review.inboxapp.com/D51
Move mailsync.backends.imapaccount -> mailsync.backends.imap.account.

Summary:
I don't think we should have direct submodules of mailsync.backends that
aren't actual backends. This code is clearly code that belongs to the
IMAP backend, and thus belongs in that submodule.

Test Plan: ./runtests passes

Reviewers: kav-ya

Differential Revision: https://review.inboxapp.com/D52
More linting and clarity cleanups