Commands for generating shell completion scripts + statically-generated bash script

[baronfel]

Part of #42397

Implements:

• provider model for shell completions
• new 'completions' command with 'script' and 'register' subcommands

Shell Support

shell	recording	static completions	dynamic completions (e.g. nuget packages)	slower, fallback completions
bash	🎥	✔️	✔️	❌
zsh	🎥	✔️	✔️	❌
pwsh	🎥	✔️	✔️	❌
nushell	❌	❌	❌	✔️
fish	❌	❌	❌	✔️

• for nushell/fish, the generate command just generates a correct-but-slow fallback wrapper
• for bash, zsh, and powershell, comprehensive and very fast static completions have been implemented, even for dynamic completions like nuget packages
• for zsh and powershell, descriptions of completion items are shown in nice menus

[baronfel]

I've implemented completion script generate for bash based partially on the excellent patterns that the Swift ArgumentParser library has used. Here's an example of the generated script (warning, 2100 lines of bash await you):

dotnet-bash-completions.txt

It works remarkably well - one of the harder parts was figuring out when truly dynamic completions were required and injecting a call to the dotnet CLI's completion command to generate suggestions for those cases. But where completions can be known statically we inject them. There is no good handling for file-based completions yet - one hurdle I faced was the very-pluggable completions model currently doesn't give any sense of attribution of the different completion sources - if I knew a given Func<CompletionContext, CompletionItem[]> was a certain kind of completion source I could maybe skip them for purposes of static script generation. As it is I had to create my own signal for that kind of data.

[baronfel]

Ok, I've updated the description. This is now ready for a review + discussion.

I've done almost all of the work in a separate library project - this is something that we should consider spinning off in the future, as the only real dependency it has is System.CommandLine. If that becomes stable then it'd be fitting for a library.

Assuming the library is implemented (and there are some baseline tests added) then the usage of the library in the dotnet CLI becomes very simple.

[Forgind]

I didn't look at shell-specific code or test code, but this looks great! I appreciated the videos in the description, but you might need to work on your typing speed (or crop the first half of the video) 😉

[Evangelink]

@baronfel I'm guessing this can only work when the options are statically registered and so it won't work for our new dotnet test experience, right?