CLI generation

I've been putting pieces in place to support the generation of opinionated CLIs that consume the SDKs generated by progenitor (code, builder, or macro). This issue is to document goals and options.

The generated CLI is not intended to be complete, rather it is intended to be complemented with additional code that handles authentication, the shape of the CLI with regard to the nested subcommand structure, and--possibly--output formatting. Each operation has a corresponding fn that takes a (generated SDK) client and an array of strings as input. It parses those strings to infer the operation parameters and invokes the corresponding client method.

I'm not sure how output will be handled--either by the generated code or by user-supplied code--but one could imagine each fn returning an impl Serialize or some sort of output handling callback.

Each operation has a corresponding "help" screen that describes the intended inputs. Query and path parameters are fairly straightforward (as are header parameters). A given parameter, input, becomes a "long argument" e.g. --input VALUE. The fn invokes T::parse(input_value) to turn the input string into the appropriate type of the parameter.

For POST bodies we have several options from which we might select one or several.

whole body from a file / stdin

POST bodies may be complex and deep. Putting the contents into a file isn't the most ergonomic, but it is the most precise and explicit. We could let users specify POST bodies in json, yaml, or toml. The help message should make the full post body schema explicit and there should be an option to output a template to make it easy for consumers to fill in the blanks. The file location could be specified with --body, a user-configurable parameter, or as an un-named, un-prepended argument (e.g. oxide instance create --project my_project_name post_body.json).

explode top-level POST body object members

Each member of the POST body structure could become its own top-level CLI argument. This introduces the possibility of a conflict between a body member and another parameter, but we could simply generate a comprehensible build failure in that case (and--for us--modify the API to eliminate the conflict).

For complex types of top level members (i.e. those that do not impl FromStr) we could allow users to provide structured input e.g. as a JSON string. While it's a bit gross to have snippets of JSON, it would be better to err on the side of making things possible.

We'd probably convert object properties to kebab-case to make them look like conventional CLI arguments.

use dot notation in parameters

For complex types we could additionally use a "dot notation" to specify subcomponents such as --foo.bar VALUE.