Run cat_file.py fixture without site customizations

This fixes a new `TestGit::test_handle_process_output` test failure
on Cygwin where a `CoverageWarning` was printed to stderr in the
Python interpreter subprocess running the `cat_file.py` fixture.

We usually run the test suite with `pytest-cov` enabled. This is
configured in `pyproject.toml` to happen by default. `pytest-cov`
uses the `coverage` module, but it adds some more functionality.
This includes instrumenting subprocesses, which is achieved by
installing its `pytest-cov.pth` file into `site-packages` to be run
by all Python interpreter instances. This causes interpeters to
check for environment variables such as `COV_CORE_SOURCE` and
to conditionally initialize `pytest_cov`. For details, see:
https://pytest-cov.readthedocs.io/en/latest/subprocess-support.html

`coverage` 7.9.0 was recently released. One of the changes is to
start issuing a warning if it can't import the C tracer core. See:
https://github.com/nedbat/coveragepy/releases/tag/7.9.0

If this warning is issued in the `cat_file.py` subprocess used in
`test_handle_process_output`, it causes the test to fail, because
the subprocess writes two more lines to its standard error stream,
which cause the line count to come out as two more than expected:

    /cygdrive/d/a/GitPython/GitPython/.venv/lib/python3.9/site-packages/coverage/core.py:96: CoverageWarning: Couldn't import C tracer: No module named 'coverage.tracer' (no-ctracer)
    warn(f"Couldn't import C tracer: {IMPORT_ERROR}", slug="no-ctracer", once=True)

On most platforms, there is no failure, because the condition the
warnings describe does not occur, so there are no warnings. But on
Cygwin it does occur, resulting in a new test failure, showing

    >       self.assertEqual(len(actual_lines[2]), expected_line_count, repr(actual_lines[2]))
    E       AssertionError: 5004 != 5002 : ["/cygdrive/d/a/GitPython/GitPython/.venv/lib/python3.9/site-packages/coverage/core.py:96: CoverageWarning: Couldn't import C tracer: No module named 'coverage.tracer' (no-ctracer)\n", '  warn(f"Couldn\'t import C tracer: {IMPORT_ERROR}", slug="no-ctracer", once=True)\n', 'From github.com:jantman/gitpython_issue_301\n', ' = [up to date]      master     -> origin/master\n', ' = [up to date]      testcommit1 -> origin/testcommit1\n', ' = [up to date]      testcommit10 -> origin/testcommit10\n', ...

where the first two elements of the list are from the lines of the
warning message, and the others are as expected. (The above is a
highly abridged extract, with the `...` at the end standing for
many more list items obtained through the `cat_file.py` fixture.)

This new failure is triggered specifically by the new `coverage`
package version. It is not due to any recent changes in GitPython.
It can be observed by rerunning CI checks that have previously
passed, or in:
https://github.com/EliahKagan/GitPython/actions/runs/15598239952/job/43940156308#step:14:355

There is more than one possible way to fix this, including fixing
the underlying condition being warned about on Cygwin, or
sanitizing environment variables for the subprocess.

The approach taken here instead is based on the idea that the
`cat_file.py` fixture is very simple, and that it is conceptually
just a standalone Python script that doesn't do anything meant to
depend on the current Python environment.

Accordingly, this passes the `-S` option to the interpreter for the
`cat_file.py` subprocess, so that interpreter refrains from loading
the `site` module. This includes, among other simplifying effects,
that the subprocess performs no `.pth` customizations.

Author: EliahKagan

test/test_git.py

@@ -773,6 +773,7 @@ def stderr_handler(line):
 
         cmdline = [
             sys.executable,
+            "-S",  # Keep any `CoverageWarning` messages out of the subprocess stderr.
             fixture_path("cat_file.py"),
             str(fixture_path("issue-301_stderr")),
         ]