Add support for negative numbers in adjacent position

[felixSchl]

🚧... this issue itself is still a work in progress...🚧

NOTE: Negative values are already supported for options, however currently they need to be bound using an equal sign: --foo=-1. This issue summarises the work that would need to be done to support negative values in the adjacent position, as well as for positional arguments. A proposal needs to be worked out that describes a fair subset of possible scenarios and how to handle them.

---

Add support for negative numbers as option arguments in adjacent position (No explicit association via '='). Further, add support for negative numbers for positionals.

Case 1 - no matching options in spec:

Usage: move <x>

There is no ambiguity here:

• $ move -1 => {"<x>": -1}

Case 2 - matching options in spec

Usage: move -1 <x>

This could result in ambiguous parses. $ move -1 could mean:

1. {"<x>": -1}
2. Error: Expected <x>. Here -1 is consumed by the -1 option, leaving <x> w/o a value.

In order to achieve case 2, nothing needs to be done. This is definitively the lowest hanging fruit.
As for case 1 - this would require a substantial change to the parser in order to prioritize adjacent groups over one another, where positional arguments would always have a higher priority than options (but only options that look like negative values??? What about stacked options?). This is a can of worms, however, as I feel as there are just so many permutations to consider. Suddenly DOS-styled switches / don't seem so stupid anymore.

Case 3/a - option arguments

Usage: foo [-1 ARG]

Must handle:

• $ foo -1 -1 => {"-1": -1}

Case 3/b - option arguments w/ repeating option

Usage: foo [-1 ARG...]

Must handle:

• $ foo -1 -1 => {"-1": [-1]}

Case 3/c - optional option arguments w/ repeating option

Usage: foo [-1 [ARG...]]

Must handle either:

• $ foo -1 -1 => {"-1": [-1]}
• $ foo -1 -1 => {"-1": [true, true]}

... this is by far not exhaustive and needs more though. In saying that, I must admit I am really put off by the idea of adding this support, considering negative values are already supported for options at the very least using the explicit = or placing the value directly adjacent to an options. I could imagine, perhaps supporting a limited subset of scenarios, such as matching negative numbers as positionals and arguments, if and only if there is no option that takes the same form. This would constitute a suitable middleground and gives the help-text author enough flexibility to design around this.