Starting in Python 3.12, global and virtual Python environments no
longer automatically ship setuptools (per the "ensurepip" item in
https://docs.python.org/3.12/whatsnew/3.12.html#removed). Projects
that use setuptools as a build backend are still supported,
including with setup.py using techniques such as "pip install .".

In Windows, the "bin" subdir of a virtual environment dir is called
"Scripts" instead. Unlike in a global environment (where no names
are universal, and "python3" and "pip3" are more common for the
Python 3 commands on some popular Unix-like systems), in a virtual
environment the "python" and "pip" commands are always present and
"python3" and "pip3" are not guaranteed to be present.

This commit changes test_installation accordingly. The CI workflows
and documentation still need to be updated.

This changes the installation instructions in README.md to
recommend "pip install ." instead of "python setup.py install". The
former is compatible with Python 3.12 which doesn't have setuptools
installed by default (so setup.py, which imports it, can be
indirectly but not directly used). This also matches the
corresponding change made in the installation unit test.

While doing so, I've also clarified the instructions, and added the
implied "cd" command as well as the "git fetch --tags" command in
the position where a later section was recently updated to mention
it should have been run.

Using "pip install ." creates the opportunity to pass "-e" to make
an editable install, which users who clone the repository to work
on changes should do, because the effect of an editable install is
only partially simulated by pytest, and so that manual testing of
changes actually uses the changes intended for testing.

This increases the length and detail of the instructions, so I've
added h4 subsections to clarify the separations between them and
make it easier for readers to find the part they're looking for. In
doing so, I've reordered these subsections accordingly. Because
greater detail can create the impression that all important steps
are mentioned, I've made the general good advice to use a virtual
environment explicit. For brevity, I have not added venv commands.

This adds a #! line to the top of setup.py, because it is a script
with the executable bit set. Although neither recent nor current
documentation in the project recommends to run "./setup.py", this
should probably have the intuitive effect of attempting to run the
script with a Python interpreter rather than a Unix-style shell.

It also uses the "env trick" in init-tests-after-clone.sh so that
script runs with whatever bash interpreter is found in a normal
PATH search. While "sh" is expected to be found in /bin on all
Unix-like systems, that is not always the case for "bash". This
change slightly improves compatibility by supporting systems that
don't ship with bash but on which it has been installed.

- Remove "gitdb" from test-requirements.txt, because it already a
  dependency of the project (listed in requirements.txt, which is
  used to build the value passed for install_requires in setup.py).

- Remove "black" from requirements-dev.txt, because it is listed in
  test-requirement.txt (which requirements-dev.txt sources).

Because tests_require is deprecated since setuptools 41.5.0 with
the intention that it will be removed in some future version (noted
in https://setuptools.pypa.io/en/latest/references/keywords.html).

It is somewhat unintuitive for GitPython to have a "test" extra, as
it makes it so "GitPython[test]" can be specified for installation
from PyPI to get test dependencies, even though the PyPI package
doesn't include the unit test themselves.

However, this makes the statement in README.md that the installer
takes care of both requirements.txt and test-requirements.txt
dependencies fully true, instead of moving further away from that.

Because it is now possible to make an editable GitPython install
with test as well as minimal dependencies installed, this commit
also updates the readme to document and recommend this.

Instead of directly running setup.py.

This allows Python 3.12 (as well as previous versions) to be used
for building. Although setuptools could be added as a development
dependency to run setup.py, using "build" instead is recommended in
https://setuptools.pypa.io/en/latest/userguide/quickstart.html.

Those docs likewise recommend only listing "wheel" in the
build-system section of pyproject.toml if setup.py actually imports
the wheel module. So this removes that. (Running "make release",
which now uses "build", will continue to build wheels.)

The "build" package is not conceptually a testing dependency, but
test-requirements.txt is currently the de facto list of all stable
development dependencies for regular use.

This is cleanup related to the previous commit. As that file grows,
it is harder to tell immediately if a particular package is in it
when not alphabetized. (The groups were also not intuitive, with
ddt listed separately from other unit test related dependencies.)

This removes the step in test_installation that did the equivalent
of "pip install -r requirements.txt", because installing GitPython
is sufficient to install all its required dependencies, and it is
more important to test that than to test requirements.txt directly.

Removing this causes the test to fail if installing the project
doesn't entail installation of the requirements necessary to import
the git module or to cause gitdb to be found in a sys.path search.

Key changes:

- Update the two CI workflows to install the project and its
  dependencies in accordance with the changed recommendations in
  README.md. (This is to test that those recommendations work,
  which the changed test_installation test case partially but not
  completely tests. The old approach to installation still works
  too, so this change on CI is not required to keep CI working.)

- Add Python 3.12 to the CI test matrix in pythonpackage.yml,
  testing it on Ubuntu. (The Cygwin workflow still tests only 3.9.)

Maintenance changes, made to avoid decreasing readability with the
other changes (and hopefully even increase it somewhat):

- Separate commands into more steps, grouping them by more specific
  purposes.

- Decrease the ways the two workflows differ from each other that
  do not represent actual intended behavioral differences. This is
  to make the important differences easier to stop, and to make it
  easier to determine when the same change has or has not been made
  to both workflows.

The omission of "set -x" was intentional and is currently necessary
on Cygwin (but not on Ubuntu), per aafb92a.

Setting the "fetch-depth" to 0 does a deep (i.e., ordinary) fetch,
fetching all commits and tags. Setting "submodules" to "recursive"
clones and checks out all submodules. These options allow commands
that were doing those things to be removed from the later steps.

This also adds "--noprofile --norc" to the Cygwin shell command
as a speed optimization (bash doesn't need to source its scripts).
That only changes the Cygwin workflow; in the Ubuntu workflow,
"--noprofile --norc" had already been included by default when no
shell was specified, so having it there is to *keep* the optimized
behavior that was already in use.

There the system python interpreter is referred to as `python3`,
at least when installed by homebrew.

If a virtual environment (created by venv or virtualenv) is active,
running "make release" or "make force_release" now automatically
installs/upgrades the "build" and "twine" packages in it. This is
only done if "make" is run in a virtual environment.

This can be a fresh environment: neither the project nor its
dependencies need to be installed in it. Because the "build" module
is not currently used in any tests and running "make" in a virtual
environment takes care of installing "build" (and "twine"), "build"
is now removed from test-requirements.txt.

The publishing instructions in the readme are updated accordingly,
to mention the optional step of creating and activating a virtual
environment, and to briefly clarify why one might want to do that.

Running "make" outside a virtual environment remains supported,
except that, due to recent changes, whatever environment it is run
in needs to have a usable "build" module.