When `rules_python` performs a hermetic bootstrap, it creates a symlink from the unzipped
Python runfiles into the location of the Python interpreter[1].

However, on Windows, symlinks are only allowed if the user is in developer mode _or_ has
a security allowance for creating symlinks. The fallback would be to create a hardlink.

Neither of these solutions work because when the symlink/hardlink is executed Windows cannot
find the required DLLs to launch Python.

I attempted a hack where we hardlink in the DDLs and/or create junctions for the directories.
Nothing works well as eventually the runfiles for the target are not found.

This may be a missing piece of coverage on the upstream ruleset.

There is an effort to look into a native launcher[2] that may or may not fix things up.

For now, mark the `pytest` Python library incompatible with Windows.

Tracking the tech-debt in #8

[1]: https://github.com/bazelbuild/rules_python/blob/1.1.0/python/private/zip_main_template.py#L289
[2]: https://github.com/bazelbuild/rules_python/issues/2500

Technical debt tracked in #9.

This vastly simplifies the `MODULE.bazel`. It allows creation of download
repositories for all versions of `cosmos` easily and creates entrypoints to
the latest version of the downloads.

This will make it _much_ easier to ingest newer versions of `cosmos` *and*
provides legacy version downloads which some users may want to pin to.

This patch does not make the extension public at this time but is designed
in a way that it could be used across the module graph to added extra
version downloads in. This would allow downstream modules to provide newer
versions of `cosmos` and the unversioned repositories would point at the
provided newer versions.

BREAKING CHANGE: A new `ape_cosmos` extension has been implemented that allows flexible downloading of `cosmos.zip` binaries.

Repositories can now be imported directly from that extension rather than `@toolchain_utils//toolchain/export:def.bzl#toolchain_export`.

Previously a repository would be imported as so:

```py
export = use_extension("@toolchain_utils//toolchain/export:defs.bzl", "toolchain_export")
use_repo(export, "ape-zstd")
```

Now the extension has all the available repositories:

```py
cosmos = use_extension("@ape//ape/cosmos:defs.bzl", "ape_cosmos")
use_repo(cosmos, "zstd")
```
BREAKING CHANGE: The `@ape//:*` aliases have been removed in favour of the more explicit `@ape//ape/toolchain/info:*` targets.
BREAKING CHANGE: `ape_binary` rule has been removed. It was plagued with runfile issues that are practically unsolvable in a hermetic way. The `ape_assimilate` rule is far superior and has been the default for the `@ape//ape:*` aliases for many releases. Finally removing the rule in lead up to `1.0.0` release.

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.