Fix #17366 (cmdline parsing of repeated --)

[carlobaldassi]

This just passes through the -- arguments from the command line after the first one (which is used as an argument separator).
Previously, passing more than one -- raised an error, which seems overprotective: after all, consider that you could even have a file called -- in the filesystem, if you're really into that sort of things...

So this fixes #17366, and it seems conceptually more correct to me (provided I didn't screw up, I'm not familiar with this code and command line parsing may have been assuming the previous behaviour for some reason, but I did not find any hint that it was).

I think this should also be backported, if it gets in.

[carlobaldassi]

Just for kicks, here is how standard command line tools behave:

$ echo > --
$ ls -- --
--
$ rm -i -- --
rm: remove regular file ‘--’? y
removed ‘--’

[jakebolewski]

👍

This is an improvement (@vtjnash raised this in #10726 (comment)). If I remember correctly this does not fix our getopt parsing though (which is why I gave up and punted). For instance if we have a file named -- with contents (println(ARGS)) then julia-dev --load -- -- foo bar baz should print out ["foo", "bar", "baz"] per system getopt parsing rules but currently fails with this PR.

[StefanKarpinski]

Seems sane to me and since @jakebolewski wrote the previous fix to this, 👍.

[tkelman]

On release-0.4 I'm a little confused what to do about the conflict here since process_options takes an args input and is a bit inconsistent about sometimes working with that argument and sometimes working with the global ARGS.