[WiP] moss: switch cli to use clap derive structs

[ermo]

This PR migrates the CLI from function-based Clap declarations to clap_derive. clap_derive allows a declarative-like definition of the CLI command tree, so it's easier to maintain and extend.

Inside moss/src/cli we'll have a root mod.rs file and one module per each subcommand. Modules may be split into other submodules when the logic becomes complex and/or multiple tests are defined (e.g. for the package subcommand).
Each module will have a Command struct with handle() as its only public method. The signature of each handle() is not identical for all Commands, but depends on the logic it performs.
Public structs/enum/functions will be at the top of each source file, private ones will be right below.

This PR fixes #196, but that issue plan functionalities that the moss backend does not yet support, and that's the reason why you'll see a bunch of unimplemented!() calls across the PR.
It also fixes #611.

Another thing I wanted to make consistent is the use verbs in their imperative conjugation instead of third-person, as these are commands. I also chose not to end phrases with a dot, like most programs out there.

I think the code could be cleaned a little (e.g. there are some Vec conversions I'm not sure they would be needed with more generic code), but that's out of the scope of this PR. I'm trying to introduce no functional and API changes here, except the parsing of CLI arguments: where possible, I'm leveraging Clap's automatic call of TryFrom to sanitize inputs, particularly for providers where I'm now passing the Provider struct.

TODO: print final CLI tree.

[ermo]

The moss package inspect alias (pin) might need to change, as the plan is to add an actual moss package pin command that saves a package in a default highest-priority cobble repo and keeps it there until the user removes it (which will typically happen when it causes the system-model to not be able to resolve).

I think pit might work, as in first-and-last-letter-of-inspect ?

[ermo]

For ease of use, we might consider allowing pkg instead of package, given we already allow repo instead of repository?

What is your thinking on potentially allowing both package and pkg as well as repo and repository, while only showing one of each in help?