redesign CLI framework

[Thomas Gilgenast]

improvements like #1 and #21 have made the lib5c toolbox much easier to use, but tackling open issues like #8, #14, and #17 still feels intimidating

a better way forward might be to redesign the CLI framework to be more reusable and generalizable

one proposed design would look like this:

• we use Python Fire to look at the kwargs of a function, expose them as command line arguments or flags, and generate help automatically from the function docstring
• we retain a similar subcommand system (supported by Python Fire)
• we retain a similar lazy import system (could be implemented using lazy_import)
• we add a "CLI middleware" layer, which could be a decorator we put on all commands exposed by Fire; its job would be to perform additional processing on args/kwargs with certain names (e.g., loading a file pattern of counts files as a counts superdict)

it is possible that we would need to improve the "top-level" functions provided for each currently existing "tool" in cases where the tool function itself currently performs complex logic - this sounds like a net win though since it would allow us to say we provide one standardized top-level interface which can be accessed identically either via scripting or over the command line. this reduces the overhead of things like having to change the default value of a parameter in two different places (and two different help strings).

we do want to use an existing CLI framework to help us with all the "generic" parts of this. in addition to Python Fire, we also considered click, but it appears to be significantly less "automatic". click might support lazy loading, but it's not very well documented and doesn't seem to behave the way we want (we actually want subcommands to be loaded at all times so that help messages are available, but we don't want to import expensive external libraries until the code is actually running - see this issue).

some research is necessary to clarify exactly how the subcommands, lazy importing, and middleware would work with Python Fire - to this end, a tech demo is provided in https://bitbucket.org/creminslab/fire-demo