middleware: verify as early as possible in app initialization that the necessary configuration is provided

In addition to verifying a random config setting, also verify that config has
been read as Paste does it, an invariant introduced in 488b52cad890.

logging: drop fileConfig initialization in make_app - backout 0d4dd9380a45

0d4dd9380a45 was a bit harmful, as it might overwrite existing good logging
configuration.

0d4dd9380a45 no longer seems relevant: Testing shows that logging for `gearbox
serve` *is* activated anyway. gearbox/commands/serve.py will invoke
"setup_logging" right before "loadapp".

We must and can assume that logging has been initialized before make_app.

Reported and based on analysis by Wolfgang Scherer.

codingstyle: trivial whitespace fixes

Reported by flake8.

gearbox: avoid duplicate logging setup when calling make_app

make_app initialized logging, while the gearbox common code does it too.
Split make_app in two to be able to avoid the redundant call.

The logging setup in make_app cannot be removed because it is needed for
'gearbox serve' and direct WSGI invocation, which does not pass through gearbox
common.py.

lib: reduce impact of bad import cycle

Follow-up to e0f31c7d0f5e.

It is unfortunate that generic lib code depends on
kallithea.lib.paster_commands.common - it would make more sense if it was the
other way around. We thus move the import down to inside the function that
needs it.

The import of kallithea.lib.paster_commands.common in db_manage triggered its
import of logging.config . middleware.py thus also got logging.config when it
just imported logging and things worked. Without this import of
paster_commands, we also have to fix the import in db_manage.

config: activate logging on 'gearbox serve'

With the switch from paster to gearbox, early logging did not show on the
console anymore. This includes the initialization logging of TurboGears2.

For our own gearbox commands, the activation of logging is done in
kallithea/lib/paster_commands/common.py:_bootstrap_config, but for 'serve'
this method is not used. 'gearbox serve' immediately runs the
'paste.app_factory' specified in setup.py, which is make_app.

Extend make_app with logging initialization in the same way as is done in
_bootstrap_config.

backend: replace Pylons with TurboGears2

Replace the no-longer-supported Pylons application framework by TurboGears2
which is largely compatible/similar to Pylons.
Some interesting history is described at:
https://en.wikipedia.org/wiki/TurboGears

Changes by Dominik Ruf:
- fix sql config in test.ini

Changes by Thomas De Schampheleire:
- set-up of test suite
- tests: 'fix' repo archival test failure
Between Pylons and TurboGears2, there seems to be a small difference in the
headers sent for repository archive files, related to character encoding.
It is assumed that this difference is not important, and that the test
should just align with reality.
- remove need to import helpers/app_globals in lib
TurboGears2 by default expects helpers and app_globals to be available
in lib. For this reason kallithea/lib/__init__.py was originally changed
to include those files. However, this triggered several types of
circular import problems. If module A imported something from lib (e.g.
lib.annotate), and lib.helpers imported (possibly indirectly) module A,
then there was a circular import. Fix this by overruling the relevant
method of tg AppConfig, which is also hinted in the TurboGears2 code.
Hereby, the include of something from lib does not automatically import
helpers, greatly reducing the chances of circular import problems.
- make sure HTTP error '400' uses the custom error pages
TurboGears2 does not by default handle HTTP status code
'400 (Bad Request)' via the custom error page handling, causing a
standard non-styled error page.
- disable transaction manager
Kallithea currently handles its own transactions and does not need the
TurboGears2 transaction manager. However, TurboGears2 tries to enable it
by default and fails, throwing an error during application initialization.
The error itself seemed to be harmless for normal application functioning,
but was nevertheless confusing.
- add backlash as required dependency: backlash is meant as the WebError
replacement in TurboGears2 (originally WebError is part of Pylons). When
debug==true, it provides an interactive debugger in the browser. When
debug==false, backlash is necessary to show backtraces on the console.
- misc fixes

config: move bulk of make_app to app_cfg.py

In preparation of migrating to TurboGears2, where almost all setup code is
in one file app_cfg.py, move the existing Pylons-based configuration to the
same location. This will make it more clear which changes are really done
for TurboGears2.

The current move does not make functional changes, the code is moved
unmodified.

middleware: drop gzipper middleware

It added unfortunate buffering, was only enabled for static_files=true, and
isn't available for TurboGears2.

If necessary, it is better to configure the web server to provide it.

middleware: replace references to Errormator with AppEnlight.

Errormator has been rebranded as AppEnlight a while back.

Errormator is no longer available. This is just a trivial rename that can't
make things worse.

middleware: use secure cookies over secure connections

HTTP cookie spec defines secure cookies, which are transmitted only over secure
connections (HTTPS). Using them helps protect against some attacks, but cookies
shouldn't be made secure when we don't have HTTPS configured. As it is now, it's
left at user's discretion, but probably it's a good idea to force secure cookies
when they can be used.

In the current implementation, cookies are issued to users before they actually
try to log in, on the first page load. So if that happens over HTTPS, it's
probably safe to assume secure cookies can be used, and to default to normal
"insecure" cookies if HTTPS isn't available.

It's not easy to sneak into Beaker's internals, and it doesn't support selective
secureness, so we use our own wrapper around Beaker's SessionMiddleware class to
give secure cookies over HTTPS connections. Beaker's built-in mechanism for
secure cookies is forced to add the flag when needed only.

middleware: apply HttpsFixup to Hg/Git operations too (Issue #132)

Fix regression from 6a0964373a30. 'Require SSL for vcs operations' might make
the protocol operations depend on the protocol type reported by a proxy even
though they don't generate URLs.

middleware: fix typo in force_https backward compatibility code

Typo was introduced in 8e26c46e9abe.

https: introduce https_fixup config setting to enable the special https hacks

Without https_fixup, correctly configured WSGI systems work correctly.

The https_fixup middleware will only be loaded when enabled in the configuration.

Second step in two-part process to rename directories.
This is the actual directory rename.