Merge pull request #205 from editorsnotes/fix-editing-bugs

Fix editing bugs
Add return to empty migration function
Add unique constraint for Document.description

This can't be done directly at the database level, since description is
an XML field, and such fields don't have equality operators in Postgres.
Instead, we create a md5 digest of the text value of that field, with
all tags, html entities, and all characters not alphanumeric or
whitespace stripped. This field then has a unique constraint in the
database along with the `project` field.
Require non-blank project description

Non-blank means that it contains at least one alphanumeric character.
Only set description_digest before saving

This means it is NOT set during cleaning, since that field would almost
certainly be excluded from ModelForm or Serializer instances, meaning it
would not get cleaned.
Add a couple tests for Document model
Mixin for project-specific item serializers

Before, we set an object's project in the `pre_save` method of a view.
That was a problem, because `full_clean` is called before `pre_save`,
meaning any cleaning/validation methods of an object which require
access to the project (i.e. unique constraints that are
project-specific) could not accurately be called.

Now, the serializer for any project-specific item should inherit the
ProjectSpecificItemMixin. This first ensures that the serializer is
passed a context containing a project, and then adds that project to the
constructed instance in the `restore_object` method. The project
attribute is then set when the restored object's `full_clean` method is
called.
Check for correct error message in document API test
Add tests for creating revisions in API calls
Register models with reversion

Somewhere along the way, these were taken out, gah...
Make revisions in API views with class decorator

Previously, we had been overriding serializers' `save_object` methods in
order to make revisions. This was never a good way to go about this for
a couple reasons. First, it required that a view pass a context variable
to the serializer indicating that a revision should be saved. Both the
view and the serializer, then, would have to know that the serializer
contained that overriden `save_object` method, which was error-prone,
redundant, and annoying. Second, that's really not what
serialization/deserialization is for. Creating revisions should be an
action initiated with views, not serializers (or forms).

This commit introduces a class decorator called
`@create_revision_on_methods`, which is pretty self-explanatory. Classes
wrapped with this decorator will create revisions when calling any of
the methods provided as arguments. So, List API views (which are POSTed
to), are decorated with `@create_revision_on_methods('create')`,
catching the `rest_framework.mixins.CreateModelMixin.create` method
inherited by that class.

It seems like this decorator could be applied to any class which
contains methods which create/change objects (ie other CBVs), so it
could prove to be useful in other places too.

(all API tests which test revision creation pass now)