getopt_long: fix case of malformed long opt

[kevans]

Summary

When presented with an arg string like '-l-', getopt_long will successfully parse out the 'l' short
option, then proceed to match '--' against the first longopts entry as it later does a strncmp with len=0.
This latter bit is arguably another bug in itself, but presumably not a practical issue as all
callers of parse_long_options are already doing the right thing (except this one pointed out).

An opt string like '-l-' should be considered malformed and throw a bad argument rather than
behaving as if '--' were passed. It cannot possibly do what the invoker expects, and it's probably
the result of a typo (ls -l- a) rather than any intent.

Reported by: Tony Overfield <[e-mail]>

[kevans]

I guess I failed to mention: Tony's original report was that ls -l- is triggered ls's COLOR_OPT processing (https://svnweb.freebsd.org/base/head/bin/ls/ls.c?revision=338028&view=markup#l435) -- which is clearly wrong based on the context.