First argument cannot be the executable name

[KathleenDollard]

When using RootCommand, if the first argument matches the command name it is stripped. This is one of at least two characteristics that differentiate RootCommand from Command. This includes the name of the executable without a suffix:

> MyExe MyExe

will strip the argument if RootCommand is the root of the parse tree. The current workaround if this is a problem is to use Command as the root. The name you use in the constructor will not matter.

This was done so that scenarios, including passing System.Environment.GetCommandLineArgs(), that include the executable will be correctly handled.

There are a couple of problems with this approach, such that I think we should consider a minor-ish change.

• How args are handled becomes a characteristic of the parse tree, not the callsite. This means that the same parse tree can't work in both scenarios. The callsite knows the source of the args.
• Telling folks to enter garbage as a name is silly. But we certainly do not want to make name optional on command, as havoc would ensue.

I propose:

• Command continue to work as today, no changes. It can be a root and we can use a meaningful unused names like "Root". In this case, the parse tree is marked to never remove the first arg.
• Alter the logic of RootCommand so that the callsite can control whether the arg is removed if it matches the exe name.

I think the syntax of this deserves discussion, but I'll throw out a couple of ideas:

cmd.Invoke(args) // No longer strips - this is a breaking change, but I think will affect few folks
cmd.InvokeStripExename(args) // ok, it is a stinky name, but I'd like to be clear here.
cmd.Invoke(stripExeName, args) // because a bool in that arg position is never currently valid?

If we can do the last, it is prettiest

@jkotas @jonsequitur @baronfel