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.
Update nginx setup documentation to make use of variables

This simplifies the configuration a bit and also allows an easy setup
of a subfolder configuration.
Add syntax highlighting for nginx sample documentation
Settings: remove obsolete ADMIN_MEDIA_PREFIX varible
Settings: in debug mode, let Django serve static files from STATIC_ROOT

With Django 1.4 the staticfiles application got included and the
variable names changed. STATICFILES_LOCAL isn't used anymore and got
replaced by STATIC_ROOT. This commit makes CATMAID's URLs config
respect that.
Settings: use MEDIA_ROOT and MEDIA_URL as storage locations

The settings files should not contain any traces to static and media
file configurations that refer to Django < 1.4 settings (like
STATICFILES_LOCAL and STATICFILES_URL).
Settings: move debug settings up a bit
Settings: add a top comment for consistency
Settings: use subdirs of MEDIA_ROOT for output in HDF5 and cropping tools