Fix app on Heroku w/gunicorn+django best practices

I really wish I could have tracked this bug all the way to its source.
The settings.LOGGING configuration was somehow getting set to {}, an
empty dictionary.  We were launching through a command like this:

python gobotany/manage.py run_gunicorn ...

This somehow resulted in: (1) our config getting read in and the
"logging" infrastructure getting correctly configured; (2) the default
config.LOGGING setting then getting set to {}; (3) gunicorn starting up
and deciding to configure our application using its own copy of the
Django configuration-init logic in its django_wsgi.py; (4) the empty
dictionary getting passed to "logging", which then complained:

ValueError: dictionary doesn't specify a version

After about an hour and a half of digging into the problem, including
several rounds of running vim on a Heroku dyno to add "print" statements
to all of the affected modules to try to find out when the dictionary
was getting cleared, I somehow stumbled across the Django docs for
gunicorn which actually recommended against using the "run_gunicorn"
sub-command at all:

https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/

"If you are using Django 1.4 or newer, it’s highly recommended to simply
 run your application with the WSGI interface using the gunicorn command
 as described above."

Since our application was created long ago and lacked a "wsgi.py"
module, I used "django-admin.py startproject" to create a fresh project,
stole the fresh project's "wsgi.py", and include it here in this commit
so that we can switch to the Right Way of doing things.  The application
now seems to start up, even under Heroku, and the error caused by the
empty logging-config dictionary appears to be resolved!  So I will never
know quite what was happening, but the exception seems to be behind us.

In other news: it was difficult to see what was going on because the
traceback lines were getting pretty randomly interspersed in the Heroku
logs; I am not sure why.  But that is what made logging into a dyno with
"heroku run bash" was so valuable: because I could reproduce the problem
at the console and see the tracebacks printed correctly, which let me
start digging into the problem.