Change how we set the timezone after loading from siteconfig.

We had a strange bug that resulted from how we set the timezone after
loading it from the siteconfig settings. We followed Django's model of
setting os.environ['TZ'] and calling time.tzset(), but this ended up
causing some interesting problems.

When running the devserver and using rbssh through Review Board, rbssh
would crash and the devserver would reload. This was due to the default
timezone being used at launch and the autoreload thread being spun up
and using that timezone for all Python module mtime verification. When
rbssh was invoked, it'd import paramiko, which imported Crypto.Random,
which had to be extracted first before the bundled native libraries
could be used.

These libraries would be saved with a time calculated from the value of
os.environ['TZ'], but the autoreload thread would calculate from the
default reviewboard.settings.TIME_ZONE, causing a mismatch in expected
values and triggering an immediate reload of the devserver, which killed
off the connection to rbssh, breaking stdin/stdout and causing a crash.

Now we don't touch os.environ['TZ']. We are going to say that it will
just mirror the actual TIME_ZONE value in settings. Instead, we'll use
Django's timezone.activate function to have that particular thread use
the new timezone for all of Django's functions.

This means functions like time.localtime will take the default (UTC)
timezone into account rather than the timezone set by the admin, but
anything that's using Django's timezone functions will do the correct
thing.

See this post for more information:

http://blog.chipx86.com/2013/01/26/weird-bugs-django-timezones-and-importing-from-eggs/

Followed my repro case for repository verification that continually broke.
It works now.

All unit tests in Djblets and Review Board pass.