#545 more slave subcommands

[Don Porter]

The [interp] command and the [$slave]
command created by [interp create] have
many, but not all subcommands in common.

Unless there's some reason not to that
I don't see, it makes sense to me to add
these subcommands to the [$slave] command:

[$slave cancel]
[$slave delete]
[$slave slaves]
[$slave target]

I would not add [$slave exists]. Instead
I would remove support of the no-argument
form of [interp exists] (2544760).

I would not add [$slave create].

I do not know whether adding [$slave share]
or [$slave transfer] makes sense.

[Colin McCormack]

I would suggest that instead of adding more functionality to [$slave], functionality should be reduced, and in fact removed to the point where [$slave ...] was equivalent to [$slave eval ...]

I think that, since the [interp {verb} $slave] commands exists to expose the functionality currently duplicated in [$interp], it makes more sense to distinguish between operating-on a $slave, and interacting-with a $slave. I think that the obvious, common and natural meaning of 'interact-with' is 'invoke', and would therefore prefer to see that as the default behaviour of [$slave]. Since this interpretation is inconsistent with the current rendering of [$slave] as an object-like command, I would argue for the removal of the (imposed) object-like [$slave] dispatcher, and by extension the addition of more functionality to this form.

I realise this is an incompatible change, and would expect it to occur in 9.0 or similar.