Fix two major concurrency-related Gmail sync bugs.

It might not be all of them, but at least it's some of them.
[SCHEMA] Fix two major concurrency-related Gmail sync crash bugs.

Summary:
Long explanation:

(bug 1)

It turns out that the relationship between ImapUid and Message was configured
as 1-to-1 for legacy reasons. (Pre thread expansion this invariant was true.)
So when we created a *second* ImapUid row for a given Message object, which,
when downloading a message from Inbox, happens to be the Inbox row, not the All
Mail row, we would set `message_id = NULL` for the first row, courtesy of
sqlalchemy. (Messages downloaded //only// via All Mail only have one ImapUid
row still.)

Then the deduplication code on the All Mail sync would call
`backends/imap/account/g_msgids()` to get a list of local `g_msgids` to
deduplicate download on. This function joins on `Message` to get the `g_msgid`.
Because `message_id` was not associated with the message for the All Mail
imapuid anymore, that message would be downloaded again and the code would
crash trying to insert the new imapuid into the database, because it already
existed, albeit with a NULL message_id. (There's also a second deduplication
stage after download/before insertion, but that ALSO fails because of the
`message_id = NULL` problem.)

I am pretty sure this bug can happen even without a restart. BUT, on restarts,
if messages are ARCHIVED from the Inbox, we delete the associated imapuids...
which, previously, would cascade to associated Message objects, assuming a
1-to-1 relationship. This would cause more `message_id = NULL` madness and more
dedupe bugs. I suspect restarts are more likely to cause this race because of
everything happening at once, though our IDLE poller during initial sync also
detects deletes.

We fix this by removing the relationship cascade and tightening
ImapUid.message_id with `nullable=False`. (Unrelatedly, we also tighten
the NULL constraint on `msg_uid`, which is inexplicably also nullable.)

Initially, `message_id` was nullable to support local delete detection, but
we're going to do that by adding `deleted_at` columns to all tables instead.
Deleted objects will eventually be garbage collected by a separate service.
Way safer.

(bug 2)

So say you download a message via `Inbox`... the Gmail sync code creates
imapuid entries for both `Inbox` and `All Mail`.  Then the `All Mail` initial
sync greenlet starts up (this race is *way* more likely after a restart). It
calls `deduplicate_message_download`, which notices that the message has been
already downloaded... and tries to create the imapuid again. Turns out this
code shouldn't create new imapuid rows when running on the All Mail folder.

We fix with a conditional check on the folder name in `add_new_imapuids`.

---

This fix brought to you by driving around SF in a minivan with a ukelele, a
long dinner with friends, a hot shower, pushups and squats, back-and-forths
with @emfree spanning days, and Moderat.

Test Plan: manually running a sync and start/stopping a few times

Reviewers: emfree, mg

Reviewed By: emfree

CC: emfree, mg, kav-ya

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