Test with M1 macOS CI runner

[EliahKagan]

This adds CI test jobs that run on ARM processors. Specifically, it adds macos-14 as a value for os in the CI test matrix. The new macOS 14 runners use Apple Silicon M1 systems (64-bit ARM CPUs), allowing GitPython to be tested on AArch64/ARM64 actions/python-versions builds of Python, such as python-3.12.1-darwin-arm64.tar.gz.

• GitHub Actions: Introducing the new M1 macOS runner available to open source!
• GitHub Actions: macOS 14 (Sonoma) is now available

Not all versions of Python that GitPython supports are currently available via actions/setup-python:

• Python 3.7 builds that can run on macos-14 runners are unlikely ever to be available, because 3.7 is end-of-life.
• Python 3.8 and Python 3.9 builds are currently unavailable, but this may be remedied; it is being tracked in Python <3.10 not available on new macOS M1 runners actions/setup-python#808.

Therefore, the new macos-14 jobs this creates are only for Python 3.10, Python 3.11, and Python 3.12. This is achieved by using exclude for the earlier versions. This way, a macos-14 job would automatically be created when 3.13 is added to python-version. (The first commit doesn't exclude anything, to verify that 3.7, 3.8, and 3.9 error out as expected. Then the second commit adds the exclusions.) If this PR is accepted, then I recommend 3.8 and 3.9 be added later, if and when they become easily available.

This does not remove or change any pre-existing jobs, but maybe it should. That is to say that this does not change macos-13 to macos-14, but instead just adds three macos-14 jobs. All six of the old macos-13 jobs, which run on Intel-based macOS 14 runners, are retained. Having nine macOS jobs may be considered excessive; even if not, builds for Python 3.8 and 3.9 may become available, and having eleven may be considered excessive. Options include:

• Rejecting or deferring this change completely.
• Taking this it as is but revisiting the matter when builds of more Python versions become available.
• Changing this to omit some versions. If that is done, the question is which ones. We could avoid doubling up Python version on macOS, but there may be a benefit to this, as it would make it easier to guess that a failure is related to the architecture. (Though we still would not know immediately because it is a different version of macOS as well.)

[Byron]

Thanks a million!

love this change and would love to try it in the hopes that MacOS runners never will be a problem. It's also interesting to see how they are the fastest machines of the bunch, and how the python version seems to make a difference as well.

Merging - let's wait and see.

[EliahKagan]

It's also interesting to see how they are the fastest machines of the bunch,

This makes sense to me because I've heard the M1 is pretty fast.

and how the python version seems to make a difference as well.

Although I expect that in general because there have been efforts in the last few versions of CPython to improve performance, I'm not sure if we're observing that or not, between the Python versions used on the macos-14 runners. Which Python versions are faster or slower than the others in the pytest step seems to be different in different runs, comparing the results in 8342f82, 9ad28c3, and 6cba89f.

[Byron]

I see, what I looked at might have been coincidence - I also thought that it's probably just luck as the jump between two python versions certainly won't speed anything up by a factor of 2 😅.