Draft of the skeleton for the charm tool. Two big details that surely needs considering before having this final: - add tests - what we'll do to provide help regarding grouped commands (currently implemented, but very hacky) That said, this draft has a lot of established functionality: - multiple commands handling - each command is responsible for - provide name and help message - declare own CLI parameters - properly do something - send messages to the user ("print to screen") through logging, in the regular levels - raise `CommandError` if wants to signal an error to the system - having each command separated in a class leaves lot of room for expansion (for example if in the future we would want to have several versions of same command, or deprecate any, or have some that needs auth, or...) - wrap command execution to properly return a retcode if something is decided to be wrong (but not hiding a normal traceback if we crash) - decide logger level according to regular `verbose`/`quiet` parameter flags, but also support DEBUG envvar for seeing debug messages *before* the parameter processing. - have both requirements files, however "prod" one is still empty (didn't need to use anything external so far) - infrastructure tests in place