Handle '--' like builtin getopts

[dodecatheon]

Terminate further argument parsing when '--' is encountered.

[UrsaDK]

Thanks for the PR @dodecatheon! It's been a while since I looked at this code and I'm a little bit swamped with work at the moment, so it might take a week or two to get back to you.

Any chance you could add a test for this change? It would give me the context in which this change is necessary and would really help with the review.

[billyzkid]

I'm not sure this PR is necessary. Based on my tests with -- (as described in #15), the current behavior seems expected.

[AndrewDDavis]

This addresses an edge case where an argument like -a-- is passed, when -a is a valid short option. In that case, the getopts built-in would stop parsing arguments after -a as if -- were passed as an argument on its own (even if -: is in the optspec string). However, getopts_long processes the argument as if it's a long option with a value of -.

[UrsaDK]

There’s already extensive test coverage for -- usage (see search results), and I believe getopts_long handles the argument terminator (--) correctly as is. I agree with @billyzkid: this PR doesn’t seem necessary.

The issue @AndrewDDavis mentioned – someone passing -a-- – arises because getopts_long didn’t support adjacent variable-value syntax (eg: -Llib). This was resolved in #20 and will be available from getopts_long v1.2.3 onward.

The only other edge cases I can think of are:

1. Someone adding - to the short option OPTSPEC, possibly trying to alter the behaviour of --. (Bad bad bad!)

2. Defining - as a one-character-long long option, leading to ---... variations.

Both are interesting points but only tangentially related to this PR. So, I'm going to close this PR, investigate the two points it raise separately, and address them individually (if we need to).