Add cargo install fallback when prebuilt binary installer is unavailable

[ChanTsune]

Summary

The generated release workflow installs cargo-dist itself via a prebuilt binary
installer (curl ... | sh). On architectures where no prebuilt binary is
published — such as riscv64 — this step fails and blocks the entire workflow.

I'd like to propose adding a cargo install cargo-dist --locked --version <version>
fallback so the workflow can proceed even when a prebuilt binary is not available
for the runner's architecture.

Background

The RISE Project recently announced the RISE RISC-V Runners (2026-03-24),
a free, managed GitHub Actions runner service backed by Scaleway bare-metal
RISC-V servers. Any open-source project can now run native RISC-V CI by setting
runs-on: ubuntu-24.04-riscv — no emulation, no cross-compilation, no waitlist.

This makes it practical for Rust projects to build and distribute riscv64
binaries through GitHub Actions. However, cargo-dist's own installer only ships
prebuilt binaries for x86_64 and aarch64, so the "Install dist" step in the
generated release.yml fails on RISC-V runners.

Proposed Change

In DistInstallStrategy::dash() / powershell(), append a fallback after the
installer command:

bash (sh):

curl --proto '=https' --tlsv1.2 -LsSf <url>/cargo-dist-installer.sh | sh \
  || cargo install cargo-dist --locked --version <version>

PowerShell:

try { irm <url>/cargo-dist-installer.ps1 | iex }
catch { cargo install cargo-dist --locked --version <version> }

This is safe because:

• GitHub Actions bash steps run with set -eo pipefail; -e does not trigger
  inside an || chain, and pipefail ensures curl failures propagate.
• On architectures where the prebuilt binary exists, the installer succeeds and
  the fallback never runs.
• cargo install --locked --version is deterministic and uses the published
  crate's lockfile.

The trade-off is that the fallback compiles from source, which is slower. This is
acceptable because the alternative is a hard failure with no workaround.