Add new commands for removing cached JDKs

[ctrueden]

The clear-cache command clears everything. But I often find myself wanting to remove "stale" versions of JDKs without starting from scratch. This commit adds two new commands for doing so:

• cjdk rm - to target specifically named cached JDKs
• cjdk prune - to remove older JDKs when newer ones are also cached

Because both commands delete local files, both are gated behind confirmation prompts unless -y/--yes is given, and the existing cjdk clear-cache is also now gated as such to avoid someone naively deleting all their cached JDKs (which happened to me this morning 😅).

I vibe-coded it with Claude, and also pushed it all as one commit. Apologies if that makes review more burdensome—although I have read through the entire patch and it looks clean and pretty minimal to me. The change of def clear_cache(ctx: click.Context) -> None adding dry_run: bool, yes: bool parameters without default values is, however, a breaking change.

[marktsuchida]

I was thinking of a prune myself, so 👍, but what is the motivation for rm? That feels out of place for cache semantics and more like a package manager (you can uv remove a package but you can't uv cache rm a specific package, for example). Can you convince me it's not YAGNI?

[ctrueden]

Well... I sort of am using cjdk like a package manager now, in the sense that whenever possible, I try to install and use OpenJDKs managed by cjdk. I have built several shell commands around it, as shown here:

• https://github.com/ctrueden/dotfiles/blob/166dcf0e056800efae670fb3187a28d668a29bfe/plugins/java.sh
• https://github.com/ctrueden/dotfiles/blob/166dcf0e056800efae670fb3187a28d668a29bfe/bin/java/jhome
• https://github.com/ctrueden/dotfiles/blob/166dcf0e056800efae670fb3187a28d668a29bfe/bin/java/jlist

So I jlist to see what I have, jswitch to change versions—j21, j17, etc. most frequently, but not always; e.g. I might need to target a more precise flavor to test specific things.

It all works great, but over time, I end up with "too many versions" installed, and I want to remove some redundant ones, but what is "redundant" is a judgment call—it doesn't always align with the prune behavior, depending on what I'm testing. Having rm is a precision tool for full control; without it, I'll end up doing it manually, which is rather tedious.

But if this sort of usage isn't aligned with your vision for cjdk, I can just write another tool like jrm or whatnot that does the delete outside of cjdk.