upToNextOption breaks with negative values

[msalmonse]

Negative numbers are parsed as options and not values.

ArgumentParser version: 0.4.1
Swift version: Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28) Target: arm64-apple-darwin20.3.0

Checklist

• If possible, I've reproduced the issue using the main branch of this package
• I've searched for existing GitHub issues

Steps to Reproduce

One of my arguments is:

@Option(name: .long, parsing: .upToNextOption,
    help: "Generate a random SVG with: #plots [max value [min value]]")
 var random: [Int] = []

The idea is to use it as —random 5 1000 -100 but the -100 is interpreted as an option and not a value.
This is similar to issue #31 but the workaround doesn't work.

Expected behavior

I expect arguments to be parsed as part of random until a valid option is encountered.

Actual behavior

Error: Unknown option '-100'. Did you mean '--bg'?
Usage: options [<options>] [<csv-name>] [<json-name>]
  See 'options --help' for more information.

[msalmonse]

I've single stepped my way through the parser and the problem IMHO is at line 535 in SplitArguments.swift. I've tried to think of a way to change the case 1 branch but I kept coming up with problems. In the end I thought of the ls -5 that someone mentioned in another issue. Long before -- became a part of the command line there was a simple solution, namely to use ls ./-5 instead.

With that in mind I would like to propose that any leading = on an argument be dropped and the remainder added as a value in the case 0 branch. This would not only apply to numbers but also to strings and it would also mean that -5 could be both an option and a value. It also seems to follow the precedent set by allowing -d=1 but not -d1 as getopt does.

The down side is that arguments that need a leading = now would need two.

[msalmonse]

No longer a problem.