Multicall should support programs that have a subcommand with the same name as the program

[fishface60]

Please complete the following tasks

• I have searched the discussions
• I have searched the existing issues

Clap Version

3.0.0-beta.4

Describe your use case

AppSettings::Multicall supports the use-case of hostname, which doesn't have applets available as subcommands for the program when run by its base program name rather than via a link.

This is implemented by giving preference to matching against subcommand names.

This makes us unable to support programs whose name as a noun is the same as what it does as a verb.
e.g. badger may be a program that sends nagging reminders until you confirm you've done the task. It doing this is badgering you, so the command to initiate it doing this could be badger badger foo@example.com.

It may be a multicall executable because part of its behaviour involves running a subcommand e.g. it sends data from a socket via pipe so it implements a significant portion of the behaviour of nc. It normally starts this subprocess by running badger nc, but it may be better optimised than the system nc and so would be useful to install a link to badger as nc.

Describe the solution you'd like

Add an additional flag to change the argv[0] matching behaviour to check against program name first.
This is a slight optimisation if the program name is expected to match more than a subcommand.

Alternatives, if applicable

We could WONTFIX this as being too obscure a use-case.

We could invert the behaviour so this is the default, and expect hostname-like programs to set their base program name to something they won't be installed as and only install links to their applets.

Additional Context

No response