Don't try to store a thread's participants in the thread table.

Summary:
Instead, compute the participants from the thread's messages and latest draft
revisions. Storing extra data on the thread seemed like a good idea for
performance, but it turns out to be tricky to guarantee correctness that
way, at least for now.

The performance hit is unfortunate (doing /threads on mg's huge mailbox on
gunks now takes ~1.7s vs 1.2s), but it's more important to be right than fast
for now.

Similarly, remove the message_public_ids column, which I originally added but
wasn't actually being used.

Fixes T113.

Test Plan:
Unit tests; sent myself a message via the API and checked that its
thread's participants were correctly set.

Reviewers: kav-ya

Reviewed By: kav-ya

Maniphest Tasks: T113

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