### What does this PR do?
Bump `rules_python` from release 1.8.3 to 1.8.4 and override to current `main` branch to benefit from a fix for `runfiles` on Windows, allowing removal of the local patch.

### Motivation
`rules_python`'s `main` branch indeed includes our contribution:
- bazel-contrib/rules_python#3578.

### Additional Notes
The `git_override` is temporary and should be removed once `rules_python` > 1.8.4 including the `runfiles` fix on Windows is published to the Bazel Central Registry.

### What does this PR do?
Bump `rules_python` from release 1.8.3 to 1.8.4 and override to current `main` branch to benefit from a fix for `runfiles` on Windows, allowing removal of the local patch.

### Motivation
`rules_python`'s `main` branch indeed includes our contribution:
- bazel-contrib/rules_python#3578.

### Additional Notes
The `git_override` is temporary and should be removed once `rules_python` > 1.8.4 including the `runfiles` fix on Windows is published to the Bazel Central Registry.

### What does this PR do?
Bump `rules_python` from release 1.8.3 to 1.8.4 and override to current `main` branch to benefit from a fix for `runfiles` on Windows, allowing removal of the local patch.

### Motivation
`rules_python`'s `main` branch indeed includes our contribution:
- bazel-contrib/rules_python#3578.

### Additional Notes
The `git_override` is temporary and should be removed once `rules_python` > 1.8.4 including the `runfiles` fix on Windows is published to the Bazel Central Registry.

Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>

With any Python version on Windows, `RUNFILES_*` environment variables
still point to an intermediate stage path instead of the module path,
causing `CurrentRepository()` to raise a `ValueError` since
`rules_python` v1.8.0:
```
ValueError: C:\Users\bot\AppData\Local\Temp\Bazel.runfiles_gh34ij5_\runfiles\+_repo_rules+cpython\my_script.py does not lie under the runfiles root C:/cache/ab1cdef2/execroot/_main/bazel-out/x64_windows-fastbuild/bin/external/+_repo_rules+cpython/install.exe.runfiles
```

This was not the case with `rules_python` v1.7.0. The issue stems from
behavior.

Since bazel-contrib#3086 came up with a corresponding workaround in
`//tests/runtime_env_toolchain:toolchain_runs_test`, the proposed fix
simply consists in moving it to `CurrentRepository()`, thus adding
another case to the workaround introduced by bazel-contrib#1634 for Python < 3.11. It
therefore leads to assuming the main module path on Windows as well.

Removing the workaround from `CurrentRepository()` would make the test
fail as follows:
```
==================== Test output for //tests/runtime_env_toolchain:toolchain_runs_test:
E
======================================================================
ERROR: test_ran (__main__.RunTest.test_ran)
----------------------------------------------------------------------
Traceback (most recent call last):
[...]
ValueError: C:\Users\user\AppData\Local\Temp\Bazel.runfiles_1f08smy6\runfiles\_main\tests\runtime_env_toolchain\toolchain_runs_test.py does not lie under the runfiles root c:\users\user\_bazel_user\cxxeswjo\execroot\_main\bazel-out\x64_windows-fastbuild-st-c530e4918e48\bin\tests\runtime_env_toolchain\toolchain_runs_test.exe.runfiles
```

Fixes bazel-contrib#3579.

(cherry picked from commit f78add7)

With any Python version on Windows, `RUNFILES_*` environment variables
still point to an intermediate stage path instead of the module path,
causing `CurrentRepository()` to raise a `ValueError` since
`rules_python` v1.8.0:
```
ValueError: C:\Users\bot\AppData\Local\Temp\Bazel.runfiles_gh34ij5_\runfiles\+_repo_rules+cpython\my_script.py does not lie under the runfiles root C:/cache/ab1cdef2/execroot/_main/bazel-out/x64_windows-fastbuild/bin/external/+_repo_rules+cpython/install.exe.runfiles
```

This was not the case with `rules_python` v1.7.0. The issue stems from
bazel-contrib#3086 which, by eliminating a wrong assumption, also brought a stricter
behavior.

Since bazel-contrib#3086 came up with a corresponding workaround in
`//tests/runtime_env_toolchain:toolchain_runs_test`, the proposed fix
simply consists in moving it to `CurrentRepository()`, thus adding
another case to the workaround introduced by bazel-contrib#1634 for Python < 3.11. It
therefore leads to assuming the main module path on Windows as well.

Removing the workaround from `CurrentRepository()` would make the test
fail as follows:
```
==================== Test output for //tests/runtime_env_toolchain:toolchain_runs_test:
E
======================================================================
ERROR: test_ran (__main__.RunTest.test_ran)
----------------------------------------------------------------------
Traceback (most recent call last):
[...]
ValueError: C:\Users\user\AppData\Local\Temp\Bazel.runfiles_1f08smy6\runfiles\_main\tests\runtime_env_toolchain\toolchain_runs_test.py does not lie under the runfiles root c:\users\user\_bazel_user\cxxeswjo\execroot\_main\bazel-out\x64_windows-fastbuild-st-c530e4918e48\bin\tests\runtime_env_toolchain\toolchain_runs_test.exe.runfiles
```

Fixes bazel-contrib#3579.

### What does this PR do?
Bump `rules_python` to 1.8.5 and drop the temporary `git_override` that
was pinning a post-1.8.4 commit encompassing our own fix:
- bazel-contrib/rules_python#3578

### Motivation
`rules_python` to 1.8.5 got released in BCR with the said fix.

### What does this PR do?
Bump `rules_python` to 1.8.5 and drop the temporary `git_override` that was pinning a post-1.8.4 commit encompassing our fix:
- bazel-contrib/rules_python#3578

### Motivation
`rules_python` to 1.8.5 got released in BCR with the said fix.

Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>