dejagnu(1) subcommand namespace planning

The patch I recently submitted to add dejagnu-report-card led to an 
interesting issue that I had not considered:  command namespace planning 
for the various dejagnu(1) subcommands.

Originally, very little thought had actually been put into this, and the 
launcher features related to this handling were arrived at mostly by 
implementation.  The idea that "report-card" and "report card" should be 
synonymous came early, as an extension of the idea that the launcher 
should recognize a command name embedded into a symlink pointing to 
itself.  The broader principle was that the launcher should chain 
together as many words as needed to form a command, or accept such a 
chain prepackaged, even into $0.

Ben raised an issue, paraphrased here as:  with this feature and a 
"report-card"/"report card" command, what happens if a future "report" 
command is added?

While discussing this, I arrived at what I believe to be the best 
solution:  The "report card"/"report-card" command introduces an implied 
"report" command that takes a fixed parameter as its first argument:  
the report type.  The first report type supported is thus "card".

This model would mean that the spaced version is the canonical name, and 
no actual command may be a word-wise prefix of another command.

Applying this to the planned "canned test stub" feature leads to an 
implicit "add" command of the form "add <what>", with implementations 
for adding empty testsuites, tools to existing testsuites, and possibly 
test groups to existing (tool, testsuite) pairs.  ("add test-group" 
amounts to "mkdir")  Most commands would not include dashes in their 
canonical names, with "add test-group" nicely highlighting the actual 
rule as an exception to the general rule:  "test-group" is logically a 
single term, like "tool" and "testsuite".


-- Jacob