Return support for multiple character short options

[twalshOG]

I know this change was intentional (#2270), but am hoping the team would reconsider.
A single character can be limiting and result in counterintuitive/weird short parameters.

Real-ish example of where multi-character shorts would be nice:

program
  .option('-k, --kill', 'kill orphaned reports')
  .option(
    '-sk, --skipExtract',
    "don't load results into database; intended for cases where you already have a fully populated database",
  )
  .option(
    '-sd, --skipPublish',
    "don't publish results the overall results; intended for cases where we are to archive the results but not push them to the entire team",
  );

[shadowspawn]

Short options with multiple-characters worked more by accident than being intentionally supported. The README was updated in Commander v3 to make the intended single-character explicit and multiple-characters was added to the deprecated documentation in Commander v9.

PR #599 added support for embedded option values and moved Commander closer to POSIX conventions which only have a single character for a short option.

There have been issues reported where people noted shortcomings in the (unsupported) behaviour: #2211 #2227. Likewise, code added to detect conflicting options did not consider multiple-character short options in #2055.

However, multiple character short options have been used in the wild! 2k hits on GitHub with this search

If we allow multiple character short options then I want it to be internally supported and not just work by happy coincidence.

Do you see multiple-character short options being used in popular command-line utilities you use? (Other than npm, which I know uses its own command-line parsing utility with shorthands.)

[shadowspawn]

A historical note after some investigation. Before Commander v5, short options with more than 1 character could not actually be used on the command line. In previous versions an option like -sk was unconditionally expanded to -s -k. So at the time I first noticed it in code in the wild and updated the README, it was not actually functional. Probably the option parsing rework in #1152 made them functional as an unintended side-effect.

[shadowspawn]

I am continuing to think about this. Using a multiple character short is not standard (POSIX, GNU) and not something I want to promote as a feature. However, I am wondering about allowing it to work in unambiguous cases since being used in the wild and will be annoying for existing users to upgrade.

So could be stricter (than before v13):

• throw for lone shorthand (because a single-dash long in disguise. c.f. Bug in regex for lone short flag #2227)
• throw for shorthand that starts with same letter as a short (because makes parsing ambiguous)

And otherwise continue to work as previously:

• no embedded value support

Only lightly documented, since not an encouraged or standard usage (and already gets used despite not being mentioned!)

Will be watching for upvotes on this issue!