consider multi-subcommand model

[salewski]

Consider whether or not a multi-subcommand interface might be a better long term approach for the ads-github-tools.

While working on issue #48, I started going down the road of implementing an ads-github-repo dispatcher command with a create subcommand. The main motivation for doing so would be to make the code for the individual subcommands more manageable, while still presenting a uniform interface for the end-user (me) working in the "single github repo" domain. This might be useful at a higher level, too, though; maybe something like:

    $ agh foo

where "agh" is short for "ads-github", and the top-level program dispatches to "ads-github-foo". More generally, it would look like:

    $ agh [GLOBAL_OPT...] SUB_COMMAND [SUBCMD_OPT...] [SUBCMD_ARG...]

Similar to the way git works, we would locate ads-github-* program on $PATH, but would give preference to our internally implemented progs, which would be installed somewhere beneath our @libexec@/@PROG@/ directory. A command dispatching to a subcommand would set up the process environment with information relevant to command line options already parsed.

The "multi-" aspect (which I'm not yet convinced is a good idea) would allow (theoretically) arbitrary levels of subdomains to be defined. More than the implicit two layers may start to get unwieldy, though, even if it would make the implementation easier. This is akin to how the aws/aws-cli program is implemented, which makes it easy enough to understand individual capabilities without needing to understand the entire program.

The ads-github-repo program, if implemented this way, would be comprised of three parts:

1. agh (top-level dispatcher)
2. ads-github-repo subcommand (for "domain" of single-repo actions)
3. create (ads-github-repo-create?) specific tool for creating a single repo on GitHub

Not really sure how that third part would be realized in code.