[attachments] Initial checking of managing attachments without duping.

Summary:
Previously we had some issues with how we were handling blocks vs
parts. In particular, an uploaded file existed as a "block" while an attachment
was a "part". Thus when you created a draft you would specify and ID for the
block that you wanted to be an attachment. When the sendmail code created the
draft it would create a 'Part' out of the 'Block'. Since the previous
relationship had Blocks deriving from Parts, this meant that a new Part would
be created, thus doing two things: copying the data (unecessary, even though it
was duped on backend) as well as creating a new "ID". A concern with this is
that a client would like to attach a block to a message and the message would
end up with file_id's that do not correspond to the original block (and the
original block would remain in place).

To solve this issue, the 'Part' object is changed from deriving from 'Block'
into a relational table between blocks and messages. Therefore, a Part has
a 'block_id' and a 'message_id' in addition to a few other parameters (i.e.
the content_disposition and walk_index). Thus, when attachments are added to
drafts, the block is not duplicated and the original block's id can be used
for the attachment.

Corresponding code needed to be changed in the mailsync which was referring to
parts assuming they were blocks. Now it uses the "Part.block" relationship
(which should have eager loading on it). Further tests have also been added to
ensure that the id does not change when a file is attached to a draft.  This
means there is now a 1-to-many relationship between blocks and parts.

Additional 'rider' change (since I was looking at this code anyway) was to
provide an improved interface to files. Most notably, blocks that are not
attached to messages can be deleted.

Test Plan: Run the regression.

Reviewers: kav-ya

Reviewed By: kav-ya

Subscribers: spang

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