[Feature]: cargo-binstall support

[kbrdn1]

Problem

`cargo install gwm` (once published to crates.io) compiles the binary locally — slow on first install, especially because `git2` with `vendored-libgit2` compiles libgit2 from C sources. Users with `cargo-binstall` would much rather grab the prebuilt binary from the GitHub Release; today they can't because the metadata isn't declared.

Proposed solution

Add the `[package.metadata.binstall]` block in `Cargo.toml` pointing at the existing release artefact naming convention:

```toml
[package.metadata.binstall]
pkg-url = "{ repo }/releases/download/v{ version }/gwm-v{ version }-{ target }.{ archive-format }"
pkg-fmt = "tgz"
bin-dir = "gwm-v{ version }-{ target }/{ bin }"

[package.metadata.binstall.overrides.x86_64-pc-windows-msvc]
pkg-fmt = "zip"
```

With this, `cargo binstall gwm` downloads the right archive, extracts it, drops the binary in `~/.cargo/bin/`. No Rust toolchain required at install time on the user's machine.

Alternatives considered

• Tell users to manually download from Releases: works but cargo-binstall is the standard Rust tooling for this and many devs already have it.
• Wait until the crate is published on crates.io to bother: not strictly necessary; cargo-binstall reads from the repo's `Cargo.toml` (or crates.io's index, once published).

Surface

build (build system, Cargo manifest)
docs / examples

Backward compatibility

No breaking change.

Example usage

```bash
cargo binstall gwm

downloads gwm-v0.2.0-aarch64-apple-darwin.tar.gz, extracts, installs.

```

Additional context

Pairs nicely with the upcoming Homebrew tap (separate issue) — different audiences, different channels, same release artefacts.

[kbrdn1]

Shipped via #173 (merged to dev). [package.metadata.binstall] added — cargo binstall gwm pulls the prebuilt release archive (.tar.gz, .zip on Windows) with no source compile. Pinned by tests/binstall_metadata_tests.rs; documented in README + install doc + skill.