Initial steps for switching to using South for migrations

These initial steps are:

 - Adding 'south' to INSTALLED_APPS
 - Making sure that South knows that our custom database
   adaptor is really just postgresql_psycopg2
 - Add some introspection rules for Integer3DField and
   Double3DField
Move the custom fields into fields.py
Remove all managed=False declarations

These tables will now be managed, using South for migrations
Fix the datetime.now default for DateTimeFields

Passing the function datetime.datetime.now as the default
causes the current time to be used on creation, whereas
previously the time used as a default would always be
the time when the field was defined.
Add back the wiki_base_url field to match the actual database

Although it should have been removed, the wiki_base_url
column is still present in the database generated via the PHP
migrations, so we have to reintroduce it to make sure that
the database match.
Add all schema-level default values to the Django field default

South doesn't create schema-level defaults for columns, so
we need to make sure that these are all present at the level
of Django's ORM.
(Integer|Double)3DField: allow some whitespace when parsing

It seems that sometimes the value that's returned from the
database has whitespace after the commas for these compound
types, so make sure that to_python copes with those.
Add back deprecated tables from the PHP version

We need the deprecated tables from the PHP version to still
be present so that they South frozen models are consistent
with extant databases.  They can be removed with South in
a later commit.
Some tidying-up of the custom field classes
Use tuples as default values for (Double|Integer)3DFields

We can't use Double3D as a default value for these custom
fields for reasons kindly explained by Andrew Godwin here:

  https://groups.google.com/d/msg/south-users/cV68iIGOnm4/4xE9e7AjX8kJ

Using a tuple is a more readable alternative though, I think.
key is the primary key of the settings table, not id
Robustify get_db_prep_value for custom fields

It seems that get_db_prep_value can also be passed a
unicode, so just reuse to_python to get the right type
no matter what it's passed.
Add basic support for the rgba compound type

This is heavily based on the other custom field types,
to the extent that the common code from these should
really be factored out at some point.
Fix a typo in a comment
Add the color column back to Textlabel (finally)
Tidy up the imports from .fields
Add the initial South migration

This migration should create a database with a scheme very similar
to one generated with the PHP migration 2013-02-01T13:53:00

The key differences are:

 - DEFAULTs will not be in the schema for most tables.
   South doesn't create these, on the basis that for a project
   where the database is only being accessed via Django's
   ORM, the default keyword argument is sufficient.

 - The types of a couple of columns have changed from bigint
   to integer in cases where we couldn't possibly need more
   than a 32-bit signed value.

 - Sequences are created slightly differently, but not in
   way that's functionally different for us.

 - COMMENT ON TABLE comments are no longer created.

 - We don't create a UNIQUE constraint on primary keys, since
   PRIMARY KEY already implies UNIQUE.

These have been checked by diffing a current database dump
and one from a database created with the South migration, which
is tricky to do precisely, but gives me some level of confidence
that it's created an equivalent database for the purposes of
CATMAID's Django backend, at least.
No longer call the PHP migrations
Merge branch 'south-migrations'

Conflicts:
	django/applications/catmaid/control/importer.py