Store new and migrated diffs as raw, compressed binary data.

Historically, due to the limitations of Django's support for database
field types, we had to store diff data as base64-encoded data. This used
to be stored on FileDiffs, and then we migrated de-duplicated
FileDiffData entries. Still, the size of the diffs added up
considerably.

This change modernizes the storage by making use of Django 1.6's
BinaryField, which allows for storing raw binary content. That means we
can store a diff as-is without dealing with base64. We then go a step
further to bzip2 compress the content. If the resulting compressed size
is smaller than the raw diff content, we store that instead. For larger
diffs, this saves a lot of space.

This new content is stored in a new RawFileDiffData table, which is
similar to FileDiffData, but with a few key differences. It uses
BinaryField, of course, but it also has a field for the compression type
(we can add additional entries down the road), and it uses numeric IDs
for the primary key. FileDiffData used hashes of the diff content, which
inflated the FileDiff table, requiring 40 bytes for the key value. That
also slowed down lookups, since a 40 byte string is more expensive than
a numeric ID. This hash still exists, but is in its own field now.

FileDiffData has been renamed to LegacyFileDiffData. Likewise, the
fields in FileDiff referencing that table have been renamed in the
model. To prevent expensive database upgrades, the table name and
the columns in FileDiff referencing it have not been renamed. The
renames are done purely on the Python side.

When accessing the diff content associated with a FileDiff, we
automatically perform the migration to RawFileDiffData. This happens
whether FileDiff is storing its own diff content, or whether it's using
a LegacyFileDiffData for storage.

This results in a typical savings of ~80% on production databases.

Reviewed at https://reviews.reviewboard.org/r/6226/