feat(cli): add completion generation support for nushell

[jcgruenhage]

I'm packaging zizmor for Chimera Linux right now (see chimera-linux/cports#4255), and Chimera Linux is shipping nushell completions where available. As a nushell user, I'd love to see nushell completions for zizmor in addition to the ones already provided. While I was at it, I also added carapace, which is a multi-shell completion engine.

The way I'm doing it here is not great, because it requires replicating clap_complete::Shell and extending it to support the additional shells. An alternative that requires less code on the zizmor side is to use something like clap_allgen, but that is not intended to be used with a Shell enum, it's intended use is to generate all completions with one function call. Going for that would be a breaking change of the CLI interface, which I'd assume would need to wait for a v2, if it's wanted at all?

A completely different alternative I'd like to bring up is generating completions during build time using a build.rs file. This would allow cross compiling zizmor and still shipping completion packages without resorting to emulation or compiling twice. That requires bigger changes though, so didn't want to spend time on this without discussing it first.

[woodruffw]

Hey @jcgruenhage, thanks for opening a PR!

As a nushell user, I'd love to see nushell completions for zizmor in addition to the ones already provided.

Cool, thank you!

While I was at it, I also added carapace, which is a multi-shell completion engine.

All things being equal, I'd prefer to defer this until there's a end-user request for it -- that keeps things simpler for me in terms of dependency review. Does that work for you?

For the rest: I'll do a review now 🙂

[jcgruenhage]

I've removed carapace_spec_clap again. For a good user experience in the CLI I think completions are one of the things that should just automatically be there. If I install a tool using my distro package manager the completions should work out of the box. Carapace only loads specs from ~/.config/carapace/specs though, not from something like /usr/share/carapace/specs, so this is not possible anyway. Considering that, I'm okay with waiting for user demand with the carapace spec generation.

I've also addressed the rest of your review comments, thanks for the feedback :)

[woodruffw]

Thanks a ton @jcgruenhage, this looks great to me!

Two small logistical things:

• Could you add an appropriate entry to docs/release-notes.md?
• Could you run make snippets to regenerate the documentation's --help render?

Other than those, I think this is good to go!

Edit: I've run the CI preliminarily, but I expect it'll fail on the above make snippets change.

[woodruffw]

BTW, don't worry about force-pushing -- I use a squash-merge workflow so having the commit history here is fine.

[woodruffw]

Thanks a ton @jcgruenhage!