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)
Set form instance attributes needed for cleaning in appropriate order

This changes introduced in this commit are similar to those in e1c7d8a
which allowed instances being created/updated from rest_framework
serializers to be cleaned properly. See the message on that commit for
more information.

The biggest difference is that, in the case of forms which create a new
object, we need to explicitly create a new instance of the model with
the `project` attribute set. This is done by extending the
`get_form_kwargs` method of django.views.generic.ModelFormMixin. The
creation of this new instance is not saved to the database, so we are
passing an uncommitted an instance throughout the form. This required
changing any code which only checked whether `instance=None` to detect
the saving a new object rather than an updated object. Instead, that
kind of logic should be replaced with checking for `instance.pk`.

These steps are also set for setting the `topic_node` attribute of newly
created topics, since there is a unique constraint on topic nodes and
projects.
Fix base API view
Remove annoying <br/> tags from documents on clean
Require django-webtest; update admin tests
Fix a large permissions bug in all admin views

When adding an item, the right permission wasn't being checked,
resulting in anyone except a superuser being denied access.
Update project permissions when canonical group created
Support for connecting to existing topic nodes

The add view for a topic will now connect to an existing topic node if
topic_node_id is present in a GET request. Attempting to connect to a
node twice will raise an error. That constraint is now also added to the
database.
Correct validate_unique for topics

Check for uniqueness of preferred_name with respect to project, not just
preferred_name alone.
Formatting, blah blah blah
Reenable editing topic summaries
Add util fns for stripping garbage tags

These include stray <br/> tags or multiple continuous <br/> tags, or
tags without text.

Sections reimplementing that logic now call those functions & new tests
added.