Use custom cargo-dist binary building workflows

[DavisVaughan]

In #301 we had to pin ourselves to Rust 1.83 due to the aarch64-pc-windows-msvc build and cargo-xwin.

cargo-xwin's docker contain pulls in 1.83 by default, and while that is configurable, it is not available to us to change. See the PR above for full info.

To free us to use Rust 1.84+, and to give us more control over the binary building process of cargo-dist in general, we should look into setting

# Whether CI should include auto-generated code to build local artifacts
build-local-artifacts = false
# Local artifacts jobs to run in CI
local-artifacts-jobs = ["./build-binaries"]

Where build-binaries.yml is our own workflow that builds binaries for all platforms of interest. For each target, we would be in charge of:

• Building the binary and wrapping it into a tar.gz (Unix) or zip (Windows)
• Computing the SHA
• Uploading both as GitHub artifacts

If we do both of those, cargo-dist should be able to pick up from there and generate the GitHub Release and the installer scripts, both of which are still very valuable parts of the cargo-dist process.

Ruff has done this. While they use maturin, I don't think we should let that deter us from looking at their approach (under the hood, maturin uses cargo-xwin and cargo-zigbuild, so at some point it's similar to what we'd manually do):
https://github.com/astral-sh/ruff/blob/main/.github/workflows/build-binaries.yml

It's going to take some effort to get the CI set up correctly for all targets (cross compilation for ARM Windows, cargo-zigbuild usage or PyPa docker containers for old Linux support), but ultimately having more full over the build process is probably going to be good in the long run due to cargo-dist having no maintainer right now, and because the build process has been a source of frustration for us over the months.

[DavisVaughan]

Note that we were able to update to Rust 1.87 #372 due to xwin updating its own Dockerfile to 1.87 as well