AppSettings::AllowHyphenValues does not document what it does beyond ArgSettings::AllowHyphenValues

[epage]

In working on #3449, I was going to make AppSettings::AllowHyphenValues be applied to the ArgSettings and remove checking for it at the app-level, but the parser has logic specific to the app level. This isn't documented and its unclear how intentional this is. If its to cover some cases, we should be letting users know. If we can remove it, all the better.

This is split ouf of #2717

[epage]

So one case where we use AllowHyphenValues at the app level is when detecting -abc is a series of short flags or a hyphen value. This has a bug outlined in #3410

[epage]

Another case for AllowHyphenValues is for falling back to treating it as a value for a positional argument. In theory, the positional argument should be setting this instead.

[epage]

The last case I identified is also about positional arguments

[epage]

I think the short case might also be about positional. If so, changing our behavior to checking the positional for is_allow_hyphen_value_set might be the way to go.

[epage]

Ideally our solution makes handling more discoverable so users don't run into problems like in #4039 (comment)

[epage]

TrailingVarArg was added in 27018b1 / #301

[epage]

Command::AllowLeadingHyphen was added in 26ecadd / #399

[epage]

Arg::AllowLeadingHyphen was added in cf9d6ce / #755

[epage]

Command::AllowNegativeNumbers was added in 9ed4d4d / #698

[epage]

I'm feeling fairly confident in the behavior in #4187