* Fixes buildtools on Windows

- Removed C++ options in .bazelrc since we by default using Bazel 7
  which defauts to c++17
- Shorten the workspace name to avoid long path issue on Windows.

Fixes bazelbuild#1210

* Fix test

Currently, `buildifier` targets don't work out of the box on Windows -
credits to Ofek for reporting.

Sadly, it turns out that two separate attempts have already been made to
remedy this:
1. In the upstream `bazelbuild/buildtools` (`go` source, but `workspace`
   suitable):
   bazelbuild/buildtools#1230 (merged)
2. `keith/buildifier-prebuilt` (`bzlmod` suitable, providing slightly
   outdated `go` binaries published by `bazelbuild/buildtools`):
   keith/buildifier-prebuilt#89 (well tested,
   but pending CI feedback... for months!)

Inspired by Tony's
[tips](https://datadoghq.atlassian.net/browse/ABLD-174?focusedCommentId=2644283),
the present change proposes the "least intrusive" change so that:
- we don't need to start a third effort (rules, `.bash` and `.bat`
  scripts),
- we benefit from the validated and merged upstream behavior,
- we don't depend on the goodwill of `keith/buildifier-prebuilt` to
  publish the version `8.2.1` of the binaries (nor subsequent versions),
- we don't have to manage a complex patch, but instead simply inhibit
  the upstream lines that we do not need, given `buildifier`
  implementations are provided by `multitool` again.

In short, this change combines the best of both worlds through a simple
indirection made possible by the configurability of upstream rules
which, unlike `keith/buildifier-prebuilt`, allow us to define which
implementation of `buildifier` to use.

Currently, `buildifier` targets don't work out of the box on Windows -
credits to Ofek for reporting.

Sadly, it turns out that two separate attempts have already been made to
remedy this:
1. In the upstream `bazelbuild/buildtools` (`go` source, but `workspace`
   suitable):
   bazelbuild/buildtools#1230 (merged)
2. `keith/buildifier-prebuilt` (`bzlmod` suitable, providing slightly
   outdated `go` binaries published by `bazelbuild/buildtools`):
   keith/buildifier-prebuilt#89 (well tested,
   but pending CI feedback... for months!)

Inspired by Tony's
[tips](https://datadoghq.atlassian.net/browse/ABLD-174?focusedCommentId=2644283),
the present change proposes the "least intrusive" change so that:
- we don't need to start a third effort (rules, `.bash` and `.bat`
  scripts),
- we benefit from the validated and merged upstream behavior,
- we don't depend on the goodwill of `keith/buildifier-prebuilt` to
  publish the version `8.2.1` of the binaries (nor subsequent versions),
- we don't have to manage a complex patch, but instead simply inhibit
  the upstream lines that we do not need, given `buildifier`
  implementations are provided by `multitool` again.

In short, this change combines the best of both worlds through a simple
indirection made possible by the configurability of upstream rules
which, unlike `keith/buildifier-prebuilt`, allow us to define which
implementation of `buildifier` to use.

### Motivation
Currently, `buildifier` targets don't work out of the box on Windows -
credits to @ofek for reporting.

Sadly, it turns out that two separate attempts have already been made to
remedy this:
1. In the upstream `bazelbuild/buildtools` (`go` source, but only
`workspace`-suitable):
bazelbuild/buildtools#1230 (merged)
2. `keith/buildifier-prebuilt` (`bzlmod`-suitable, and providing
-slightly outdated- `go` binaries published by `bazelbuild/buildtools`):
keith/buildifier-prebuilt#89 (well tested, but
pending CI feedback... for months!)

### What does this PR do?
Inspired by some of @aiuto's
[tips](https://datadoghq.atlassian.net/browse/ABLD-174?focusedCommentId=2644283):
> [1.b.] instead of pointing to the toolchain type defined in
buildifier_prebuilt, point to buildifier via multitools.
> [2.a.] revert prebuilt_buildtools.json to
5fd6373

The present change proposes the "least intrusive" change so that:
- we don't need to start a third effort (own rules, `.bash` and `.bat`
scripts),
- we benefit from the validated and merged upstream behavior,
- we don't depend on the goodwill of `keith/buildifier-prebuilt` to
publish the version `8.2.1` of the binaries (nor subsequent versions),
- we don't have to manage a complex patch, but instead simply inhibit
the upstream lines that we do not need, given `buildifier`
implementations are provided by `multitool` (again).

In short, this change combines the best of both worlds through a simple
indirection made possible by the configurability of upstream rules
which, unlike `keith/buildifier-prebuilt`, allow us to define which
implementation of `buildifier` to use.

### Describe how you validated your changes
I used another branch to verify this works under Windows as well:
https://github.com/DataDog/datadog-agent/blob/026042234ee811fd1641a2417893c08008860186/.gitlab/bazel/build-deps.yaml#L39

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two disinct community efforts wrt runner
script templates, the present/upstream `bazelbuild/buildtools` and the
derived `keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts like for Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- bazelbuild#1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.

This change aims at making `buildtools/buildifier` more modular and
easier to consume by enabling use of prebuilt binaries without pulling
in unnecessary dependencies - while strengthening upstream as the
authoritative home for runner script templates.

Today, `buildifier/BUILD.bazel` exposes two different sets of rules:
- exports for runner script templates (`runner.bash.template`,
  `runner.bat.template`) as well as `README.md`,
- `go` build & `sh` test rules which require external repos (`rules_go`,
  `rules_shell`) even for consumers who don't need to build the
  `buildifier` binary.

It is worth noticing there are two distinct community efforts on runner
scripts, the present/upstream `bazelbuild/buildtools` and the derived
`keith/buildifier-prebuilt` (Bazel Central Registry module).
These drift apart over time, leading to unsynchronized contents
(`factory.bzl`, `runner.bash.template`) and efforts, e.g. on Windows
support:
- #1230
- keith/buildifier-prebuilt#89 (open for a year)

Intended benefits of this change:
- decoupling: by moving `go_binary` and `sh_test` targets into
  `buildifier/cmd`, the top-level `buildifier/BUILD.bazel` no longer
  requires `rules_go` nor `rules_shell`,
- flexibility: users can either build binaries from source (via
  `//buildifier/cmd`) or configure rules to use prebuilt binaries (e.g.
  via `multitool`) while still consuming the same upstream runner script
  templates,
- backward compatibility: aliases keep `//buildifier:buildifier*`
  working by delegating to `//buildifier/cmd:buildifier*`.