This fixes a new `TestGit::test_handle_process_output` test failureon Cygwin where a `CoverageWarning` was printed to stderr in thePython interpreter subprocess running the `cat_file.py` fixture.We usually run the test suite with `pytest-cov` enabled. This isconfigured 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 byinstalling its `pytest-cov.pth` file into `site-packages` to be runby all Python interpreter instances. This causes interpeters tocheck for environment variables such as `COV_CORE_SOURCE` andto 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 tostart issuing a warning if it can't import the C tracer core. See:https://github.com/nedbat/coveragepy/releases/tag/7.9.0If this warning is issued in the `cat_file.py` subprocess used in`test_handle_process_output`, it causes the test to fail, becausethe 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 thewarnings describe does not occur, so there are no warnings. But onCygwin 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 thewarning message, and the others are as expected. (The above is ahighly abridged extract, with the `...` at the end standing formany 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 previouslypassed, or in:https://github.com/EliahKagan/GitPython/actions/runs/15598239952/job/43940156308#step:14:355There is more than one possible way to fix this, including fixingthe underlying condition being warned about on Cygwin, orsanitizing 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 conceptuallyjust a standalone Python script that doesn't do anything meant todepend 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 loadingthe `site` module. This includes, among other simplifying effects,that the subprocess performs no `.pth` customizations.