…ndaries

Also add the target for the test that was missed in the merge of bazelbuild@ad381cb.

Work towards bazelbuild#25834

Closes bazelbuild#25863.

PiperOrigin-RevId: 758308509
Change-Id: Iafb5854c8986eb3f3b34d96e4f94990f6914f47a
(cherry picked from commit b8ef3f3)

### What does this PR do?
Bump `bazel` version from [8.4.2](https://github.com/bazelbuild/bazel/releases/tag/8.4.2) to [8.5.1](https://github.com/bazelbuild/bazel/releases/tag/8.5.1).

To make that happen, we also need to:
- specify which `bash` to use on Windows when evaluating **repository** rules, for compatibility with bazelbuild/bazel#26927:
  ```
  ERROR: /path/to/external/bazel_tools/tools/test/BUILD:23:10: in sh_binary rule @@bazel_tools//tools/test:collect_coverage: 
  Error in fail: No suitable shell toolchain found:
  * if you are running Bazel on Windows, set the BAZEL_SH environment variable to the path of bash.exe
  ```
  (actual job output: https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1349246422#L77)
- bump `rules_go` from (implicit) [0.57.0](https://github.com/bazel-contrib/rules_go/releases/tag/v0.57.0) to (explicit) [0.59.0](https://github.com/bazel-contrib/rules_go/releases/tag/v0.59.0) for bazel-contrib/rules_go/pull/4493 to be compatible with bazelbuild/bazel/pull/27296:
  ```
  Error: 'Facts' value has no field or method 'clear'
  ```

### Motivation
1. this upgrade alone brings several improvements and bug fixes, among which:
- bazelbuild/bazel#27117
- bazelbuild/bazel#27296
- bazelbuild/bazel#27417, covers:
  - bazelbuild/bazel#25834
  - bazelbuild/bazel#25863
  - bazelbuild/bazel#25864
  - bazelbuild/bazel#25870
  - bazelbuild/bazel#26698
- bazelbuild/bazel#27531
- bazelbuild/bazel#27560
- bazelbuild/bazel#27564
- bazelbuild/bazel#27705
- bazelbuild/bazel#27995
- bazelbuild/bazel#27996

2. `bazel` 9.0 is due soon, so better off favoring incremental bumps.

### Additional Notes
Leveraging [the latter](bazelbuild/bazel#27996) might allow us to later reconsider whether we'd like to go back to the `--remote_cache` flag (instead of the `--remote_executor` flag that we had to switch to in #44962).

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