Consider parsing more option value syntax

First we need to define what are short options and long options. Long options: options with names longer than a single character Short options: options only one character long Option name is anything after - or -- (or / for Windows style as a future extension).

1. Allow short options to have their values concatenated to their names: -g3, -lzlib (if in the future we allow unified option prefix like a single / or -, we may want to disable this parsing mode)
2. Allow long options to separate their names and values with = (or : for Windows style as a future extension): --foo=a.txt. This does not work for nargs>1.

See also https://docs.python.org/3/library/argparse.html#option-value-syntax

Agreed on the definitions.

1. I'd like to keep support for compound arguments, e.g., ps -aux which is a combination of three short options: -a, -u and -x.
2. I'm very interested in additional option value syntax like = and :

1. I'd like to keep support for compound arguments, e.g., ps -aux which is a combination of three short options: -a, -u and -x.

We can let users express the intention of not to distinguish long and short options with its - or -- prefix. For example, for Windows commands, /s and /q cannot be combined as /sq (you can try that using the rmdir command) because it's totally possible to have a /sq command. So when users says .option_prefix('/'), compound arguments are not parse. Similar, .option_prefix('-') supposes to support javac -style -options.