Throw for unsupported option setup

[shadowspawn]

Pull Request

Problem

People who try and use unsupported Option flags do not get an error, and have to discover themselves that there are problems at runtime.

Placeholder issue: #2235
See: #430 #479 #908 #1718 #1862 #2211 #2222 #2227

Solution

Throw for unsupported Option flags, especially for known issues — too many flags, and short flag with more than one character.

This will break some existing programs that had undetected problems. (It broke one of our tests!)

ChangeLog

• breaking: throw during Option construction for unsupported option flags

[shadowspawn]

Released in Commander v13.0.0

[p3k]

Hi @shadowspawn! We noticed some of our commands break with v13 because they are configured with more than one long flag. The idea is to provide a shorter version without using a one-letter option, e.g. --es and --ecmascript or --ddsg and --donaudampfschifffahrtsgesellschaft (just kidding with the latter one).

Now that multi-letter options are also throwing an error, this feels quite limiting. I get the point of considering POSIX-compatibility with multi-letter options (I am always confused by those e.g. in Gnu’s find command) – does the same apply to multiple long flags or did you have other considerations?

[shadowspawn]

No, I had not considered multiple long options. Like multi-character short options, they just happened to work. There is an issue open about multiple-character short options, and I'll add a reference to multiple longs: #2307

Hyrum's Law: https://www.hyrumslaw.com

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

[shadowspawn]

This PR was released in Commander 13.0

Support for dual long options to allow a short-ish flag was added in Commander 13.1: #2312