UnrecognizedArgumentHandling options are cheking in all commands

Describe the bug Whe an app has sub commands like app |-> subcommandA |-> subcommandB

if subcommand A has UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect the app will throw and UnrecognizedCommandParsingException when I run app subcommandB --nissingParameter because subcommandB not allow unrecogized aruguments.

To Reproduce Create the followin structure app |-> subcommandA |-> subcommandB

Set UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect to app, subcommandA and let subcommandB without UnrecognizedArgumentHandling option.

Then run app subcommandA --missingArg You will see an UnrecognizedCommandParsingException Expected behavior With he following app structure: app |-> subcommandA |-> subcommandB

where subcommandA has UnrecognizedArgumentHandling = UnrecognizedArgumentHandling.StopParsingAndCollect then when a call to app subcommandA the app should run the command not mater if subcommandB has not UnrecognizedArgumentHandling

In other words we should not check that if any command nas not UnrecognizedArgumentHandling we should only check if the matching command has the correct UnrecognizedArgumentHandling value

[scott-xu]

My PR has no API change at all. If the sub command’s UnrecognizedArgumentHandling/OptionNameValueSeparators is not set, it will inherit the setting from parent. The root command will have the default value if not been set.

[natemcmaster]

I think the real fix is to adds new concept, subparsers. The current design mixes too many responsibilities into the subcommand structure. The API isn’t designed to handle parser behavior which varies from subcommand to subcommand. If someone is interested in taking up this work, let’s design some API for how to separate CommandLineApplication’s parsing responsibilities into something that could be scoped per subcommand.