Release v0.7.2

Bump to 0.7.1

Bump to 0.7.0

Bump to 0.6.4

Bump to 0.6.3

Bump to 0.6.2; opt out of LTO in aur PKGBUILD

v0.6.1 added `-fuse-ld=bfd` thinking the failure was rust-lld being
broken. It wasn't — bfd reproduced the exact same undefined-symbol
wall, which tipped me off that the linker was a red herring.

The real root cause: makepkg.conf defaults to `OPTIONS=(... lto)` and
sets `LTOFLAGS="-flto=auto"`, which gets injected into CFLAGS. The `cc`
crate then compiles ring's C/asm sources to LTO bitcode (GIMPLE)
instead of native ELF objects. ring's static archive ends up full of
bitcode; the Rust-driven final link doesn't run gcc's LTO front-end on
those objects, so every ring_core_0_17_14__* symbol comes back
undefined.

Opt this package out of LTO via `options=('!lto')`. Reverts the bfd
RUSTFLAGS hack and the now-unnecessary binutils makedep. Verified with
a clean local makepkg run.

Bump to 0.6.1; force GNU bfd linker in aur PKGBUILD

v0.6.0 from the AUR failed to install on Arch with a wall of
"undefined symbol: ring_core_0_17_14__*" errors at link time. Arch's
rust package ships rust-lld as the default linker, and rust-lld 19/20
sometimes fails to resolve ring's C/asm-built symbols (compiled by
ring's build.rs into a static archive). The GNU bfd linker handles
this correctly, which is why CI (Ubuntu, bfd default) and
`cargo install`-driven builds work.

Set RUSTFLAGS in the PKGBUILD's build() to override to bfd, add
binutils to makedepends. AUR-only fix — Homebrew, debian, freebsd,
and npm binaries are unaffected.

Bump version to 0.6.0; source ROSIE_VERSION from CARGO_PKG_VERSION

First release of the Rust rewrite. Public API + CLI + lockfile + npm
package layout are unchanged; the implementation is wholly new.

Refactor src/lib.rs to pull ROSIE_VERSION via env!("CARGO_PKG_VERSION")
so the runtime version stays in lockstep with Cargo.toml automatically
— removes the two-edits-per-release footgun the C codebase had.

Bump version to 0.5.6

Bump version to 0.5.5