[BUG] A couple of issues with getopt() -- user needs a consistent way to signify end of options

[enunez]

Test case 1:

  {
    config: { _meta_: { args: 1 } },
    command: "node program.js foo",
    expected: { args: ['foo'] },
  },

Fails. Program output: Option "--_meta_" requires 1 arguments, but 0 were provided

Test case 2:

  {
    config: { move: { key: 'm', args: '*' } },
    command: "node program.js -m 1 2 3",
    expected: { move: ['1', '2', '3'] },
  },

Fails. Actually returns: {move: true}. I would've expected either {move: ['1', '2', '3']} or {move: true, args: ['1', '2', '3']}. It's an ambiguous command, because you're not currently allowing the user a way to signify the end of options (e.g., using --). So as a workaround, we can add a dummy option like -e to signify the end of options, but that's kinda kludgy. I tried to hack a -- implementation with the config option end: {key: '-' }, but that didn't work. Key has to be a letter, heh. Oh well.

In some configurations, I can get around these ambiguity limitations by entering the "positional arguments" before the options, but that's really unintuitive. What we really need is the ability to do something like, node program.js -m 1 2 3 -- foo bar. That would resolve the ambiguity issue -- it would make it clear that 1 2 3 are the values for the -m switch, and that foo bar are the positional arguments.