Replace <pod> <service> with shorter naming conventions & rationalize

[emk]

Our current argument convention looks like this:

cage [options] run [exec options] <pod> [<command> [--] [<args>...]]
cage [options] exec [exec options] <pod> <service> <command> [--] [<args>..]
cage [options] shell [exec options] <pod> <service>
cage [options] test <pod> <service>

Nobody likes typing <pod> <service>, especially when service names are often globally unique. Additionally, the run command needs some way to specify a pod normally, but to also allow the specification of a service. And logs (#7) raises some design issues of its own.

After some discussion with @dkastner, we'd like to propose three argument types:

• <pod>, for commands which can only accept a pod.
• <service>, for commands which can accept a service. This can be specified as either $POD/$SERVICE, or if the service name is unique, just $SERVICE.
• <pod_or_service> looks for $POD, $POD/$SERVICE and a unique $SERVICE, in that order.

With this design, our subcommands would look like:

cage [options] logs [log options] [<pods_or_services>..]
cage [options] run [exec options] <pod_or_service> [<command> [--] [<args>...]]
cage [options] exec [exec options] <service> <command> [--] [<args>..]
cage [options] shell [exec options] <service>
cage [options] test <service>

Comments and feedback are welcome!

[erithmetic]

I like the third option the best. I think it covers the 80% usage case.

[emk]

Well, my proposal is that we really need to support all three: pod only, service only, or either a pod or a service. We have examples of all three commands, and if we try to force everything into one scheme, we'll need to think through issues in the implementation very carefully, because not all commands naturally have the ability to work on both