Design, implement command line parser

[sasha-gil]

A command line parser specified below provides features familiar to users of cargo:

• There is a set of Commands, "help" gets automatically added to the list. No more than one command is specified as the default command. When no command is specified as the default, "help" becomes the default command. A command name consists of lower case letters, plus it can contain dashes ("-") - but each dash is surrounded by letters. Most likely we do not want to allow digits and special characters other than "-" in command names. Each command can be flagged as "aliased" - that allows to use a single letter shortcut for this command (as in "cargo b" being a shortcut for "cargo build"). Naturally if two aliased commands have names starting with the same letter, that's an error.

• There are several lists of Parameters. No more than one parameter list is specified as Global (applicable for all commands). These parameters are akin to function arguments, considering each command as a function. Thus, each parameter has a name - most likely we want to enforce same rules for parameter names as for command names. Similarly to commands, parameters can be aliased. The difference on usage is - the parser automatically prepends each full parameter name with two dashes, and a single-letter alias for a parameter name with a single dash. Some parameters are flag-like self-sufficient "words"; each flag-like parameter is an optional bool parameter which value is false by default. Each non-flag-like parameter (a "value parameter") assumes a value specified right after a correspondent parameter name; however, the value can be omitted in case when a given parameter is provided with a default value. Some value parameters are specified as obligatory; non-obligatory parameters are optional. Some parameters are specified as "positional", meaning that names for positional parameters can be omitted. However, either all positional parameters come without names, or all positional parameters come with names. Example: let's consider "convert" command that takes two aliased obligatory positional parameters: an "input" file name and an "output" file name. In that case "convert infile outfile", "convert -o outfile --input infile" are correct commands, but "convert infile --output outfile", "convert -i infile outfile" are incorrect. A value parameter can have a default value that is used when the value is not provided after parameter name in the command line. Note that this situation differs from the situation when that parameter is optional and it is not provided (in this situation it has no value, it is missing in the parser output).

• Do we allow optional positional parameters? It makes sense only when a command has exactly one optional positional parameter. Example: "help" command has one optional positional parameter that provides a command name to get help about. When that optional parameter is missing, "help" output lists all commands and global parameters with short descriptions.

• Do we allow non-positional obligatory parameters? For the sake of simplicity let's prohibit that, making "positional" and "obligatory" synonyms here.

• An optional value parameter can be specified as "repeatable", meaning that it can appear more than once - values will be accumulated in a container.

• All parameters in Global set must be optional (non-obligsatory), thus they are not positional.

• A value parameter can be provided with a validator. The command line parser component comes with a number of stock validators, and some of stock validators are combining validators. "All" and "Either" are combining validators that take two or more subordinated validators: "All" requires that all subordinated validators must approve the value; "Either" requires that at least one of subordinated validators approves the value. "Not" is a combining validator that takes exactly one subordinated validator and inverts its decision. In case a parameter has both a default value and a validator, the validator must approve the default value.

• In the parser output, parameter values are represented as strings by default, however, we want to provide a conversion option to one type from a set of predefined types. That option goes hand in hand with predefined validators.

• We want to have a generic system that allows to provide custom validators, convertors - all predefined validators and convertors are defined as stock "custom convertors". In the parser output values are represented by a sum type resembling "variant" (is there a pattern of that kind in Rust?).

• Each command can be provided with one or more parameter lists. The "more than one parameter list" option here is useful for reusing same parameter list for different commands. When processing several parameter lists, the system considers them concatenated when deciding on the order of the combined sequence of positional parameters. Even though each parameter list is checked independently (considering restrictions like no clashes on aliased parameter names), the concatenated list gets checked as well.

• Each command and each parameter is provided with an obligatory short description - that is used for automatic implementation of the "help" command (also duplicated as a global aliased "help" parameter). A command might also have a long description that is used when that command is the parameter of "help" command - instead of the short description used for that command when "help" has no parameters.

• A command can be provided with a custom validator that validates a given combination of parameters. There are no stock non-combining command validators but combining validators (All / Either / Not) can be used with custom command validators.

• The "help" optional aliased flag parameter is automatically provided to each command. When it is present, no other parameters are allowed (even obligatory) - this situation is specail-cased.