Implement help command #14
Description
Following the discussion of the PR #11
Programs which follow PROGRAM OBJECT ACTION CLI pattern often support PROGRAM HELP and sometimes PROGRAM OBJECT HELP. E.g. git help, ip help, ip route help, ipa help, and so on. Those are often in addition to PROGRAM -h/--help. It's just what people often expect from this kind of CLI, which is distinct from the one used by classic *nix tools such as ls and find. That's what I'm referring to.
I would be OK with diverging from that for the sake of simplicity. However, I have a feeling we will need that solved eventually. If we can think of plausible other "entities" which won't need the --db option, then I'd rather leave it "entity-specific" and not make it global at all, then.
One example could be a command listing possible values for one of the kpet run generate parameters, which are hard-coded, and are not part of the database. I.e. it needs to be kpet run generate --thingy FOO and there would need to be kpet thingy list producing FOO, BAR, BAZ, but FOO, BAR, and BAZ are defined in the source code and don't need the db to be output. So kpet thingy wouldn't need the --db option. OTOH, we can require it to be supplied anyway in the case we might transition to storing the list in the database after all.
Another consideration is how to structure the (eventual) configuration file, in case the --db option is left entity-specific. Should it then be specified separately for each entity type in the configuration file too? Or should it be global there? Coming from this angle, I would say it should be global both in the configuration file and on the command line, but perhaps each entity should verify that it's present by itself. I.e. tell the parser the --db is optional, but complain if it's missing in each entity interface which requires it.