This is analogous to the 3.7-related CI change in gitdb that was
part of gitpython-developers/gitdb#114, as
to part of gitpython-developers/smmap#58.

Since some tests are not yet passing on 3.13, this does not add
3.13 to CI, nor to the documentation of supported versions in
`setup.py`. Note that the list there is not enforced; GitPython can
already be installed on Python 3.13 and probably *mostly* works.

(See gitpython-developers#1955
for details on other changes that should be made to fully support
running GitPython on Python 3.13.)

Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their names while others don't (this corresponds to `experimental`,
which was always set to some value, but was set in different ways).

This fixes that by:

- Listing all tested versions, rather than introducing some in an
  `include` key. (The `include:`-introduced jobs didn't distinguish
  between originally-present matrix variables and those that are
  introduced based on the values of the original ones.)

- Replacing `os` with `os-type`, which has only the first part of
  the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver`
  to each matrix job, defaulting it to `latest`, but using `22.04`
  for Python 3.7 on Ubuntu.

This should also naturally extend to adding 3.13, with or without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.

As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.

But right now this allows the workflow to fail.

Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their names while others don't (this corresponds to `experimental`,
which was always set to some value, but was set in different ways).

This fixes that by:

- Listing all tested versions, rather than introducing some in an
  `include` key. (The `include:`-introduced jobs didn't distinguish
  between originally-present matrix variables and those that are
  introduced based on the values of the original ones.)

- Replacing `os` with `os-type`, which has only the first part of
  the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver`
  to each matrix job, defaulting it to `latest`, but using `22.04`
  for Python 3.7 on Ubuntu.

This should also naturally extend to adding 3.13, with or without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.

As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.

But right now this allows the workflow to fail.

It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.

Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their names while others don't (this corresponds to `experimental`,
which was always set to some value, but was set in different ways).

This fixes that by:

- Listing all tested versions, rather than introducing some in an
  `include` key. (The `include:`-introduced jobs didn't distinguish
  between originally-present matrix variables and those that are
  introduced based on the values of the original ones.)

- Replacing `os` with `os-type`, which has only the first part of
  the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver`
  to each matrix job, defaulting it to `latest`, but using `22.04`
  for Python 3.7 on Ubuntu.

This should also naturally extend to adding 3.13, with or without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.

As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.

But right now this allows the workflow to fail.

It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.

As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.

But right now this allows the workflow to fail.

It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.

For now, this omits macOS and Windows from the 3.13t ("threaded")
tests.

The plan in gitpython-developers#2005 is to start without them, and no OS-specific
problems have been identified so far. In particular, in the
previous commit that adds 3.13t without excluding any operating
systems, all tests in the macOS job passed as expected, and the
Windows job had the same failure with the same message as in gitpython-developers#1955,
with no XFAIL changed to XPASS (which, if present, would suggest
GC differences meriting further exploration of 3.13t on Windows).

For now, this omits macOS and Windows from the 3.13t ("threaded")
tests.

The plan in gitpython-developers#2005 is to start without them, and no OS-specific
problems have been identified so far. In particular, in the
previous commit that adds 3.13t without excluding any operating
systems, all tests in the macOS job passed as expected, and the
Windows job had the same failure with the same message as in gitpython-developers#1955,
with no XFAIL changed to XPASS (which, if present, would suggest
GC differences meriting further exploration of 3.13t on Windows).

For now, this omits macOS and Windows from the 3.13t ("threaded")
tests.

The plan in gitpython-developers#2005 is to start without them, and no OS-specific
problems have been identified so far. In particular, in the
previous commit that adds 3.13t without excluding any operating
systems, all tests in the macOS job passed as expected, and the
Windows job had the same failure with the same message as in gitpython-developers#1955,
with no XFAIL changed to XPASS (which, if present, would suggest
GC differences meriting further exploration of 3.13t on Windows).