logging: Stop forcing pre-Python 2.5 legacy config behavior.

The `disable_existing_loggers` option to the `logging.config` module
turns on a rather complicated behavior of disabling some, but not all,
loggers that might have been already configured when the call to
`logging.config.dictConfig` or `logging.config.fileConfig` is made:

> This behaviour is to disable any existing loggers unless they or
> their ancestors are explicitly named in the logging configuration.
  (https://docs.python.org/3/library/logging.config)

Turns out the only reason this is there is as a compatibility hack to
match the behavior of Python 2.4 and below.  See the thread where the
new behavior was introduced: https://bugs.python.org/issue3136

Just as the author of the new behavior explains in that thread from
2008, the legacy behavior forces all logging configuration to be
awkwardly centralized in one place.  That makes the code harder to
read, and it perennially causes confusion when a perfectly
normal-looking `logging.getLogger` call at the top level of one module
mysteriously has no effect, while that in another module works fine,
under the influence of the details of what gets imported when.

So, switch to the shiny new behavior of Python 2.5.  Here LOGGING is a
Django setting which just becomes an argument to logging.config.dictConfig.

This may cause a few of the logfiles in ZULIP_PATHS to become active
that have been dormant for a long time.

zproject/settings.py

@@ -1048,7 +1048,7 @@ DEFAULT_ZULIP_HANDLERS = (
 
 LOGGING = {
     'version': 1,
-    'disable_existing_loggers': True,
+    'disable_existing_loggers': False,
     'formatters': {
         'default': {
             'format': '%(asctime)s %(levelname)-8s %(message)s'