Abort on ambiguous subcommand names

[dcantah]

Currently it's possible to have two commands with the same _commandName by mixing a combination of the automatic command name generation based on the type name, and explicit use of CommandConfiguration's commandName parameter. For example, if we edit the math examples Add command to have a commandName of "multiply" this is allowed currently:

./.build/debug/math multiply 2 3
5

The behavior today is whatever subcommand is registered in the tree first is what will resolve for that command. So, Multiply in this example is permanently shadowed.

This change just makes sure there's no occurence of this happening in any level of the tree of potential subcommands, and if so we'll abort early.

Note

I can't imagine this happens too often, but the detection logic will also be useful to verify clashing aliases+subcommands for this change as well https://github.com/apple/swift-argument-parser/pull/627.

Checklist

• [x] I've added at least one test that validates that my change is working, if appropriate
• [x] I've followed the code style of the rest of the project
• [x] I've read the Contribution Guidelines
• [x] I've updated the documentation if necessary

[dcantah]

@swift-ci please test

[dcantah]

Gentle ping on this 😆. I'll start with this change as https://github.com/apple/swift-argument-parser/pull/627 can feed from it.

[dcantah]

Let me draft this until I have time to fix up the way we validate this

[dcantah]

Closing this as adding some validations here seems very tricky, if we do want this I'm glad to brainstorm with someone