Reimplement project-sepecific permissions

This completely changes (and completely improves) how we handle
project-specific permissions.

1. A new mixin called ProjectPermissionsMixin must be inherited by any
object which should have project-specific permissions. These permissions
are recorded & updated after any database sync operations (syncdb or
migrate). They are just the permissions that django automatically
creates (add, change, delete + any defined custom model perms) for
models that inherit from ProjectPermissionsMixin.

1a. Instead of inheritence, it might be possible/desirable to use the
registration pattern used by, e.g. Django's admin & reversion. That
might go something like `project_permissions.register(model)` somewhere
in models.py

2. I introduced a new model: ProjectRole, which has a name and is
connected (one to one) with a Group which is automatically generated.
That group can contain any of the permissions described in (1) above.
If a project role is defined as a "super role", it will automatically
have all such permissions.

3. Here was the tricky part-- there were several ways that we could have
checked project level permissions. This could have been done in a custom
authentication backend with object-level permissions. That would have
looked something like `user.has_perm('main.change_note', object)`. Since
the ProjectPermissionsMixin allows us to get the "affiliation" of an
object from the required `get_affiliation` method, we could have then
checked if a user had the specific permission in a role in the project.
The reason I didn't like this that much is because it's redundant-- you
have to define the object's app and relevant permission IN ADDITION TO
the object.

The best solution to this would be to be able to say
`user.has_project_perm(project, 'main.change_note')`. This is much
clearer, because we *are* using permissions in a much different way than
django's admin-- we don't want to know if a user has a certain
permission, we want to know if a user has a certain permission in the
context of a certain project.

However, it's not possible to add custom methods to the User model
unless we substitute our own custom User model (which may or not be
beneficial in the future, but would certainly be time-consuming). So,
somewhat disappointingly, I added this method to the UserProfile model.
I like this solution because it makes it *very* explicity how
permissions are checked, so there wouldn't be any slipping up and, for
example, forgetting to pass the object to `has_perm` in the first
solution.

4. There is a new management command `delete_stale_project_perms` which
will remove any permissions that we no longer want to define as project
permissions from any groups which still reference them. This might
happen if we remove a custom permission from a project-specific model,
or if we add to the list of ignored project permissions in
editorsnotes/main/management/__init__.py