Make settings.py into a package

The reason for doing this is that it is problematic to have a single
settings.py that is responsible for introduce new settings, handling
overrides, and initializing code paths that use settings.

The problem that turned up is that settings that are *introduced* lower in
the lexical layout than the statements for responsible *overriding*
settings are left incapable of overrides. Any statement placed in the
canonical default settings should be subject to overrides, unless
explicitly setup to not allow them. We accumulated a bunch of settings
that a developer may wish to override during development but cannot
easily do so.