Implement better validation of how CLI arguments are used together

[florelis]

Description of the new feature / enhancement

The current validation of arguments seems to miss many combinations of arguments that don't make sense together. For example, the upgrade commands allows winget upgrade --all -v 1.0 (version is used only when upgrading single package, not all of them) or winget upgrade -m myManifest.yaml --accept-source-agreements (sources are not used with local manifest, so there are no agreements).

We should improve that validation, preferably in a way that makes it easier to extend as we add more arguments.

Proposed technical implementation details

I think we could create "categories" of arguments and define the rules on top of them. For example, for upgrade there are arguments for selecting the package (e.g. id, version), arguments for selecting multiple packages (--all, --include-unknown), and arguments for the sources (source name, REST source header, agreements). We could define rules on top of them like disallowing arguments for both single and multiple packages, or for sources when including a local manifest. Adding a new argument to one category would include it in all existing rules easily.

[JohnMcPMS]

Indeed, Powershell's parameter sets was something I had considered when this was originally written. At the time it wasn't really worth it, but I assumed we could just add it later. I still think we could do so easily.

I would argue for keeping them separate as in sets, rather than tagging each argument with flags. That way, each set can have custom documentation (if needed) for the argument.

[Trenly]

@florelis - Is this resolved with the above PR?

[florelis]

@florelis Is this resolved with the above PR?

I think the PR does what I wanted so I'll close this. Maybe in the future we'll want to do what @JohnMcPMS suggested about sets, but that can be a different issue.