Fix the new summary index on MySQL.

MySQL has a quirk (many say a bug) where the max index length is based
on the actual number of allowed bytes, rather than characters, in a
VARCHAR. On InnoDB, this max length is 767 bytes. Each Unicode character
in MySQL takes 3 bytes, though. If you're running InnoDB with utf-8 and
create an index on a column with a max length over 255 characters (or
765 bytes, you'll either get an index safely capped to 255 (if running
MySQL < 5.6) or an error (if running MySQL 5.6+).

Note that this is not a problem for Postgres or SQLite. It's also, in
this case, not a problem for MySQL with MyISAM, since the max length
there is 1000 bytes.

Our options for the summary field were to either truncate from 300
characters to 255 (destroying bits of history), to remove the index
entirely, or to cap the index ourselves. The first two options are
terrible, and the third is not directly supported by Django.

Turns out what we can do is create per-engine SQL initial data files
that will create the appropriate indexes. This will only work for new
installations, though, but covers that case.

We can then create an evolution that, depending on the database type,
invokes custom SQL for creating the index. On MySQL, that custom SQL
will contain a key length cap, and for everything else, there will be no
cap (since they don't support such a concept).

Reviewed at https://reviews.reviewboard.org/r/6513/
Update the "change" field with submitted perforce changesets.

When a perforce changeset is submitted, it will often be given a new number in
order to ensure that changeset IDs are monotonically increasing. One
long-standing request we've had is to update the 'change' field on review
requests when this happens.

Without a hook on the SCM side, we don't have any notification that a changeset
was submitted, but it turns out that we do already query the perforce server to
determine whether or not to display "(pending)" next to the change number. This
change adds some logic to find whether or not the change number was updated,
and if so, store the new value. As part of this, we also now cache the
information on whether a changeset is pending or not.

I've also removed the now-unused get_pending_changesets() method.

Testing done:
Created and submitted several perforce changesets, and saw that the 'commit_id'
field on both the review request and any drafts was updated properly when the
page was reloaded after submitting the change. Verified that caching is working
as expected.

Ran unit tests.

Fixes bug 2272.

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