Try again at NoteSection model

In b8cac7a I got rid of note sections in favor of just using citations.
At the time, I said that if we wanted to go back to note sections, "we
can make [different types of sections] into their own models, and have
note sections be a generic foreign key to them". That's what this commit
does, except using concrete inheritence instead of generic
relationships.

The three types of note sections I've included:
	* Citations
	* Text
	* references to other notes

These distinct sections are all stored in different tables, but in most
cases, we will want to retrieve them by getting all of a notes'
sections, regardless of their subclasses. To accomplish this without
hitting the database much, I've added django-model-utils as a
requirement. It includes a manager for such a use case. See the article
"Automatic Downcasting of Inherited Models in Django" [1] for the basis
of this manager.

An advantage of this split is that we will be able to add different
types of sections in a modular way. Next I'll need to make serializers
and templates for each type of new section.

[1] http://jeffelmore.org/2010/11/11/automatic-downcasting-of-inherited-models-in-django/
Migrate data over for Citation note sections

Changes citations with a generic relation to a note -> Citation note
sections
Update note section imports in forms

This is broken, but it will stop raising an Exception
New "distributed" topic model(s)

Topics are now recast as "topic nodes" that contain connections to
projects. For now, those connections are names, summaries, and topic
assignments. In the future it's easy to imagine structured data will
fall in the same category.

Also added fixtures for basic multi-project & user setup. The tests for
the new topics rely on these fixtures.
Migrate data to distributed topic models

Migration 0089 is a beast. I'm truly, truly sorry. OK, to it now--

In 20fef76 I introduced several new models (TopicSummary, TopicName,
TopicNode) to replace the Topic model, in order to make "topics" (the
concept) more modular and more fitted to having multiple projects work
on them. This commit migrates data over to the new topic models and
begins adapting everything else to work with them. I will first describe
the four migrations and then summarize what has been changed in the
architecture of the site.

A few of these commits take a really long time to run on our existing
database, so I'm going to include a soundtrack to go with each of them.

* (0088) John Cale - "Guts"
All TopicCluster objects from the `refine` module deleted. This is no
longer how we will deal with "merging" topics that refer to the same
thing. See 20fef76, especially the new methods introduced in the
TopicNode model to see the new methods of merging "pointers" to a topic
rather than topics themselves.

* (0089) Killing Joke - "Unspeakable" (repeat 10x very, very loud)
It's actually embarrassing how much time this commit stole from my
life-- chiefly because there were so many complicated DB transactions
involved that *had* to go through django's ORM. Basically what this
migration does is make new TopicNode, TopicName, TopicSummary,
TopicNodeAssignment, and Version (from reversion) objects based on the
previously existing Topic models. These new objects were most often
based on old Version/Revision data. I made some pretty simple heuristics
to determine ownership by project, but there are definitely (relatively
few, I hope) stragglers which will need to be manually edited. As with
previous data migrations (e.g. 0085 converting citations -> note
sections), this migration had the unintended consequence of forcing me
to clean up some of our old reversion data.

* (0090) Faure - Impromptu no. 2 in F minor, op. 31
Delete old topic models (Alias, TopicAssignment), as well as most of the
Topic model (but not the model itself.. see 91)

* (0091) The Beach Boys - "Please Let Me Wonder"
Add a new field (merged_into) to the Topic model, so that topic objects
point to the TopicNode that they were folded into in 0089. We may
decide to delete these altogether-- I haven't decided. For now, the old
topic URLs give a 301 redirect to their respective TopicNode pages.

So now, for the rest of it-- I temporarily disabled all of the apps in
our projects outside of 'main', because they all need to be adapted in
turn to the new topic model. That includes the API, custom admin pages,
and refine apps. I'm not sure what will come next-- adapting those as
they are now, or getting the permissions situation under control.
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
DB migrations: assign projects to Documents/Notes

This migration contains migrations for document and note objects,
explicitly assigning them to specific projects in the same way that
ae2763a did so for topics.

Migration 0097 contains a PL/pgSQL script that will not work on Postgres
versions before 9.0, since it uses the DO command, introduced in 9.0,
for executing an anonymous function.

We may want to treat documents like clusters that can refer to the same
thing in the same way we treat "TopicNode" objects and project-specific
pointers (i.e. names, summaries, assignments) to them. If we want to do
that, we can go back and edit 0097 before we apply these migrations to
the production site.
Update tests for updated main models
Migration for updated project membership layout

Instead of being defined in an "affiliation" field in UserProfile, a
user's membership in a project is managed through ProjectRole objects,
introduced in 1c68d81, which are intermediate models between Projects
and Groups.
Substitute custom User model

This involved creating a few tricky migrations.

0101: Rename tables that auth.User used so that they pointed to main
instead of auth. This included the primary user table as well as the M2M
tables betwen {permissions,groups} and users. Additionally, I made
migrations from other apps (reversion, django-rest tokens) depend on
these, so that our auth tables would be created by the time they were
needed in FKs in those.

0102: Migrate all information from old UserProfile model to our custom
User model. This was mostly zotero {keys,ids}. Unfortunately, it was
also the M2M table between notes and assigned users, in which I had
(stupidly) used UserProfile as a foreign key. I made the change to this
table in a pl/pgSQL function for ease.

0103: Delete UserProfile.

0001: Create auth_user table that would have been done in
syncdb so that it can be renamed in 0101.

Additionally, I made changes to the tests so that everything passes and
fixed wherever django.contrib.auth.models.User was imported. There's
definitely lots to fix with templates (for example) referring to
UserProfiles
Add container for cnxs between Projects & Topics

In ae2763a, we migrated to a more distributed topic model. However, I
made a mistake when I created the migrations 008{7,9}. While the
TopicName, TopicSummary, TopicNodeAssignment models were appropriate,
there should have been a container that grouped all those into one
Project -> TopicNode connection, ala the model being developed by the
W3C's Linked Data Platform. To do so, not only did I have to edit the
models, but I had to update the frozen ORM for every revision we made
since 0087 (I know, I know... My lord do I know...). Let's hope that
this is the end of changing the database around.

Additionally, the biggest data migration (0089) let a lot of stuff fall
through the cracks, chiefly because a lot of our revisions lacked a
user_id field specifying the creator of a version/revision. So before
migrating to the distributed topic stuff, I added a function to fix
those user-less revisions (through inspecting last_updater or creator
values in their versions).

I'm tired.
Make topic name a field of ProjectTopicContainer

Which means eliminating the TopicName model and updating all previous
ProjectTopicContainer versions
Tweak project topic containers, fix tests
Remove deprecated files & functions

Including all references to django's admin, and our previous API views
(superseded by editorsnotes.api)
Remove all references to UserProfile
Add some missing methods in main/models
Refactor urls
Split up our admin views & forms into separate files

Conflicts:

	editorsnotes/admin_custom/views.py
Reenable admin_custom in INSTALLED_APPS, unbreak things a little bit
Split main/views.py into a module; refactor URLs