According to `@platforms` `ppc` is equal to `ppc64` as they have `ppc32` to denote 32bit.

BREAKING CHANGE `@ape//:*` targets have been removed.

The aliases pointed at `@ape//ape/toolchain/info:*` targets which is a more descriptive target. Use those.

Removal of `reuse.software` in favour of a Bazel solution.

We will eventually be able to generate SBOM and that can integrate back into `reuse.software`.

We need to add more code owners but they are correct at this time.

We exclusively use `MODULE.bazel` and `WORKSPACE` will be removed in Baezl 9.

Remove the `WORKSPACE` to prevent any confusion and usage of legacy dependency management.

Bazel will select newer module versions if the `compatibility_level` is the
same. This warnings are often noise, so we will disable them by default.

Needed to avoid overfetching and attempting to fetch `zig`
on `non-arm64-macos-darwin` devices.

These have been deprecated for a few releases and were badly
named. These targets are now under `@ape//ape/toolchain/info:*` targets. `@ape//ape:*` targets are `exec`/`target` configuration flexible.

Allows downstream users to select a `target` configuration
compatible APE target.

The `@ape//:*` targets are explicitly for the `exec` configuration.

This has lead to confusion when selecting a APE binary target that is needed
for the `target` configuration.

New `@ape//ape/toolchain/info` targets have been added to make the target name
explicit. A toolchain will _always_ be for the execution platform.

This rule only depends on local data so can be marked as such.

If a Linux user has Wine installed with the `binfmt_misc` registration,
an APE binary is picked up and ran under the Wine runtime.

Normally, this does not occur, as we force execution under the launcher.

However, Python `sys.executable` will return the original binary so
any Python script that uses `sys.executable` with `subprocess` will
unexpectedly run under Wine.

Assimilating the binary on Linux avoids this situation. In all other cases
we can symlink to the binary.