Decouple Execution from Parsing

This library shouldn't tightly couple argument parsing and command execution. This is a mistake every cli library seems to make, at the expense of making the library generally useful. Parsing command-like strings into arbitrary types should arguably be explicitly the focus, with an optional layer for "automatic" executions of commands. In particular, use cases that involve REPL's, like bots, suffer from this coupling.

The results of parse should be either an instance of the filled out subcommand data or an error state. In addition. usage information should be publicly queryable to support custom usage displays (i.e. a version of makeUsage that returns an html snippet)

#48

Start by reviewing the library's current parsing and command-execution boundary, then inspect the parse and makeUsage APIs. Done means parsing can return filled subcommand data or an error independently of execution, while usage information is publicly queryable for custom displays.

Written by the indexing model from the issue text.