[SCHEMA] Explicitly schedule syncback actions, instead of using the transaction log.

Summary:
Fixes T167, by removing the offending code altogether.

Instead of inferring syncback actions to execute from the generic transaction
log, explicitly store them in the new ActionLog table. This provides the
following benefits:

 * It's easier to ensure that syncback actions are executed when they should
   be. For example, if a user marks a single message as read via the API, we
   want to sync that back. But if we change a message's read status in
   mailsync, we don't want to schedule a syncback action. It's currently
   impossible to distinguish those two scenarios just by interpreting the
   transaction log. Similarly, we had to clunkily distinguish between tags that
   were set via the API and tags that were set from mailsync.

 * The SyncbackService doesn't need to process the *entire* transaction log.

Test Plan: Unit tests, and manually san-checking syncback actions.

Reviewers: kav-ya

Reviewed By: kav-ya

Subscribers: spang

Maniphest Tasks: T167

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