ci: use targeted Rust build caches

[cpu]

I was getting tired of the very long rcgen CI times and aimed codex at it. I don't particularly find joy in fiddling with the cache settings so taking an actions dep on Swatinem/rust-cache to get everything working & tuned out-of-box seemed appealing to me.

Here's codex's description of the change/rationale:

The hand-written actions/cache setup stores the full target directory under keys that require an exact Cargo.lock hash. This has three practical failure modes:

• the repository cache reached 9.86 GB of GitHub's 10 GB quota, so useful entries are evicted;
• the stable build and coverage jobs share a key, allowing coverage to save instrumented artifacts that the stable build cannot reuse; and
• any lockfile update misses every prior entry and rebuilds all dependencies.

Clippy, one of the longest-running jobs, is not cached at all.

Use Swatinem/rust-cache for Clippy, the platform build matrix, and coverage. It derives keys from the job, compiler, and Rust build environment, falls back across lockfile revisions, and removes workspace, incremental, stale, and unused artifacts before saving.

Keeping that Rust-specific policy in the cache action avoids duplicating fragile path, key, and cleanup logic in the workflow. It also reduces cache pressure while preventing incompatible jobs from sharing entries.

After initial cache population, this reduced average CI wall time from ~18m18s to ~2m19s (87% faster) and runner usage by roughly 63%.

[djc]

Hell, yes!