setup: avoid setuptools 67 - it can't handle celery's broken pytz dependency

With setuptools 67 or later, launching Kallithea fails as:

$ gearbox serve -c my.ini --reload
15:56:54,111 ERROR [gearbox] Expected closing RIGHT_PARENTHESIS
pytz (>dev)
~^

The `packaging` vendored in setuptools cannot handle the broken syntax
`Requires-Dist: pytz (>dev)` in
venv/lib/python3.11/site-packages/celery-5.0.5.dist-info/METADATA .

The old celery version currently used by Kallithea is wrong, and setuptools has
moved on after a reasonable grace period. We thus have to work around and avoid
latest setuptools.

See https://github.com/pypa/setuptools/issues/3889 .

py3: officially support Python 3

All tests pass and no known regressions.

cli: convert 'gearbox make-config' into 'kallithea-cli config-create'

... and update documentation.

setup: don't use setuptools 34 - it has indirect conflicts with the celery version supported on the stable branch (Issue #266)

Setuptools==34 requires packaging>=16.8 which has an unconstrained requirement
of pyparsing ... but actually it doesn't work with pyparsing==1.5.7 ... which
is required by celery<2.3 ... which this version of Kallithea requires.

Celery has been upgraded on the development branch but we don't want to do that
on the stable branch.

gearbox: make a make-config sub-command available again

Drop the old kallithea-config command line tool and rework it to a replacement
for the make-config paster command. Make-config was experimental in paste, it
doesn't exist with gearbox, it was tied to pylons, and we already have the
luxury problem of having two ways of doing almost the same thing. This is a
good opportunity to get rid of one of them.

This replacement tool is Kallithea specific and doesn't need to be told that it
is Kallithea it has to create a config file for. The command should thus
perhaps be given a Kallithea specific name instead of the very generic name ...

gearbox: replace paster with something TurboGears2-ish that still works with the Pylons stack

This is a step towards moving away from the Pylons stack to TurboGears2, but
still independent of it.


Some notes from the porting - it could perhaps be the missing(?) documentation
for migrating from paster to gearbox:

Note: 'gearbox' without parameters will crash - specify '-h' to get started
testing.

Replace paster
summary = 'yada yada'
with the first line of the docstring of the Command class ... or override
get_description.

Note: All newlines in the docstring will be collapsed and mangle the long help
text.

Grouping of commands is not possible. Standard commands (for development) can't
be customized under the same name or hidden. (Like for paster, the conceptual
model also assumes that the sub-command naming is namespaced so commands from
other packages won't conflict.)

The usage help is fully automated from the declared options.

For all deprecated Commands, replace paster
hidden = True
with gearbox
deprecated = True

Note: config_file, takes_config_file, min_args and max_args are not available /
relevant.

The gearbox parser is customized by overriding get_parser - there is nothing
like paster update_parser.

Gearbox is using argparse instead of optparse ... but argparse add_argument is
mostly backwards compatible with optparse add_option.

Instead of overriding command or run as in paster, override take_action in
gearbox. The parsed arguments are passed to take_action, not available on the
command instance.

Paster BadCommand is not available and must be handled manually, terminating
with sys.exit(1).

There is no standard make-config command in gearbox.

Paster appinstall has been replaced by the somewhat different setup_app module
in gearbox. There is still no clean way to pass parameters to SetupAppCommand
and it relies on websetup and other apparently unnecessary complexity. Instead,
implement setup-db from scratch.


Minor change by Thomas De Schampheleire: add gearbox logging configuration.
Because we use logging.config.fileConfig(.inifile) during gearbox command
execution, the logging settings need to be correct and contain a block for
gearbox logging itself. Otherwise, errors in command processing are not even
visible and the command exits silently.

docs: restructure Kallithea upgrade instructions

This creates a separate "Upgrading Kallithea" section, instead of trying
(and failing) to repeat the same information for each installation page.
Trying to maintain upgrade instructions for each installation method was
perhaps overly ambitious. In practice, only the Linux instructions were
up-to-date.

(Incidentally, this is kind of a throwback to Kallithea 0.1, which also
had a separate upgrade section.)

docs: add advice of upgrading pip and setuptools in new virtualenvs

Withtout this, the new virtualenv might have setuptools version 12 while the
URLObject dependency mock fails because it requires setuptools>=17.1 .

docs: consistent spacing around headings

Start out with 2 empty lines before/after for top level, decrease for deeper
levels.

docs: cleanup of casing, markup and spacing of headings

Mostly stuff found and fixed by Søren, extracted here to separate things.

Other uses of title casing might be debatable, but here it was just a few
documentation headings that clearly were inconsistent with the majority.

docs: update Windows installation documentation for Windows 7/Server 2008 R2 and newer

Update to the Windows installation documentation following my setup experience
on our production server.

Changes :

* Use of Microsoft Visual C++ Compiler for Python 2.7 which simplifies matter
versus installing Visual Studio 2008 Express, because it removes the need
to use the Visual Studio 2008 command prompt. It is also a lot smaller to
download and install. Unfortunately, this means the instruction will only
work on the same platforms as those which are supported by the compiler.
* For that reason, I split the documentation into newer and older Windows.
* Added more explanations where I feel it was necessary based on my experience
* Added explanation on Git (Warning : I did not try this part)
* Instructions assumes x64 instead of Win32.
* Clarified titles
* Grammar

Potential issues:

* I have the user install pip system wide so that virtualenv installation is
easier (especially if using Python 2.7.9 which already includes pip). One
may prefer to install virtualenv and the pip in the virtual environment (I
know of no good reason, but it could happen).
* Removed some line feeds that I found useless. I do not know the .rst
format, they might be needed. It makes no difference when the documentation
is generated using make.bat, so I am not sure

Potential improvements:

* Instructions on using srvany.exe to install as a Windows service
* Instructions to make a reverse proxy using Apache
* Instructions to make a reverse proxy using IIS