Support Python 3.13

[EliahKagan]

Tasks for full Python 3.13 support (the "Audit all ..." tasks can arguably be deferred if necessary):

• All platforms: Upgrade Sphinx packages to not use imghdr (#1954)
• Windows: Figure out what index.remove('/only/looks/absolute') should do on Windows
• Windows: Audit all other uses of os.path.isabs in GitPython
• Windows: Audit all choices GitPython makes based on whether paths are absolute or relative
• All platforms: Add Python 3.13 setup.py classifier (though it's not needed for installation)

Python 3.13 has been out for a few months now (and even has a patch release, 3.13.1), but I have not yet gotten to finishing this. I believe GitPython already mostly works on Python 3.13, including the recently released current version of GitPython as well as other recent-past versions. But there was a change to the behavior of os.path.isabs on Windows in Python 3.13 that affects some functionality. The problem affects only Windows; GitPython should already completely work with Python 3.13 on other operating systems, though of course it is possible that other version-specific bugs are not yet discovered.

Unlike on Unix-like systems, most paths on Windows that begin with a directory separator are actually relative paths, because a path that begins with a single \ or /--rather than, for example, \\?\, \\.\, or \\hostname\--is relative to the root of the current drive (unless it begins with \??\ and is used in a context where that syntax is accepted). But ordinary drive-relative \ paths are reported as absolute in os.path.isabs prior to Python 3.13, even though pathlib.Path functions do not misreport them in this way.

This rightly causes one test to fail. In addition, this points to a likely area of confusion when handling paths in Windows, and the code covered by the failing test, as well as other code that checks through os.path funcitons or pathlib.Path methods if paths are absolute or relative on Windows should be examined.

I believe it is to avoid breaking code that relies on the old behavior that earlier versions of Python have not been updated to fix os.path.isabs for these kinds of paths. But any code that relies on that is likely to be doing the wrong thing. More broadly, any code that assume a path is absolute if and only if it begins with a directory separator is likely to be doing the wrong thing on Windows, even if it does not make use of library functions that encapsulate this assumption.

The original pull request description follows, including some elaboration related to the tasks.

Python 3.13 is currently a release candidate (3.13.0rc1). Initially all this draft PR does is enable it for CI.

This is not ready to merge. There are two failures on CI:

On Windows, a test fails due to the change in 3.13 to os.path.isabs. I hope to fix that here, but I definitely have no objection if someone else wishes to fix it (which can supersede or, if desired, build on whatever ends up here). I'll also try to expand on that and related issues, here or elsewhere. It is not obvious what the best fix is. This is because the confusion that led to the old behavior of os.path.isabs (and the skew between its behavior and that of Path.is_absolute), as well as possibly other conceptually related issues, seem also to affect GitPython, including the code that leads to the current 3.13 test failure.

On all platforms, generating documentation fails (though the CI results don't show it for Windows because the unit test step fails first). This happens because 3.13 removes a number of deprecated modules, and one of them is imghdr, which the old version of Sphinx we've been using attempts to import. This is fixed in #1954, and I plan to rebase this PR if that is merged.

---

In addition, though possibly not in this PR, because we currently list every version we support in the metadata defined in setup.py, once there is good reason to believe that GitPython works properly on 3.13, it should be added. (This is purely informational, and unrelated to the version range used to determine whether and what versions of GitPython are installable for what versions of Python.)

That could be done either in this PR or subsequent to it, depending on whether the changes here are sufficient to provide that confidence. But I do not take it to be a goal of this PR to do that; once CI is passing without suppressing anything, I think this would be ready. Then we would have CI in place that would help with further changes aimed at improving 3.13 support or fixing 3.13-nonspecific problems discovered while investigating 3.13-specific matters.