Improvements to command-line.parser

[mrjbq7]

Some ideas for improvements to make to the command-line.parser vocabulary:

• support short option codes (e.g., -h and --help) for a single option
• support windows conventions for help (e.g., /?)?
• allow short option codes to disambiguate conflicting codes (e.g., --help and --host), perhaps matching exactly and then optionally fuzzy-matching if not exact?
• support -tvfz to mean -t -v -f -z (would -HPup HOST PORT USER PASS work?)
• treat options defined as -f different from --foo?
• support a "counting" type (e.g., -vvv to mean -v 3)
• non-zero exit codes on errors in with-options (maybe using a different MAIN: syntax like MAIN-OPTIONS:) or perhaps it returns an exit code so you can do OPTIONS [ ... ] with-options exit?
• should default be allowed to be a quotation ( -- default )?
• support equivalent of +extend+ from argparse
• support --host=HOST in addition to -H HOST and --host HOST?
• support command aliases to give additional long form versions (e.g., -f, --foo, --foo-bar)
• allow registering converters for classes used in argconvert
• rename parse-options and with-options to parse-arguments and with-arguments?
• how to set a default of t and a const of f?

Some comments from discord:

when implementing fuzzy matching of options, have you considered backwards compatibility? I guess you copied python's argparse behavior. If there is a --build flag today --b is unambiguous, if you add --batch in a later version you just introduced a breaking change

Looking at that, and setting aside my dislike of how verbose T{...} is in general, looks cool I do note that it doesn't seem to have a way to define short aliases for longer options, though E.g. if you have --host and --help, -h is ambiguous; you can't configure it to always be eqv to --help without, it looks like, duplicating the option entry

Same deal if you want a short option that isn't a prefix of a longer one, e.g. -x/--one-filesystem