Experiments dragging legacy databases into Django ORM.  Eventual
goal is to get all RPKI CA databases into Django ORM / South world.

Needed to construct a shared settings.py for everythign to use, which
will require some extra hackery:

* The GUI has a lot of settings.py stuff that's not relevant or wanted
  for anything else, so make them conditional on presence of an
  environment variable which we set in rpki.wsgi.

* settings.py will need to read rpki.conf, and it's not practical to
  screw around with custom startup everywhere, so location of
  rpki.conf must configured by rpki.autoconf or RPKI_CONF environment
  variable, and programs that want to offer a -c option to select the
  location of rpki.conf will need to implement this by whacking
  RPKI_CONF.

At this point the basic mechanism seems to work, although I'm still
flailing on some of the field types and no doubt could do a better job
with the models.

I'd like to get rid of the historical name of the "self" class, it's a
horrible choice for Python, but predates the decision to use Python.
"Tenant" is my current theory for a replacement name (shorter than
"ResourceHolder").

rpki-manage.py will need to be updated to know about the new shared
settings file, and we may need to pay attention to the magic
environment variable that enables the GUI settings, as there may be
rpki-manage functions that require the GUI stuff to be present.

Sequence for resetting all of the migrations if we change the initial
models yet again:

* Whack the databases (drop/create, run yamltest, whatever) back to
  the pre-Django state.

* Run ./manage.py syncdb to initialize South.

* Run this to regenerate the initial schema and data migrations:

  rm -rf rpki/*db/migrations
  for i in pubdb rpkidb
  do
    ./manage.py schemamigration --initial $i
    ./manage.py datamigration $i copy_legacy_data
  done

* WARNING WARNING WARNING this will throw away all the carefully
  hand-written data migration code, so don't do this without a backup.

  As a practical matter, having the previous versions of the
  migrations under version control is the best form of backup, since
  this lets one use vc-diff and emacs diff mode to selectively reapply
  bits and pieces from the previous migrations.

* When it's time to run the migrations, it's just

  ./manage.py migrate

  See --help options to migrate, --list is particularly useful.
