(Irony not intended...)

Error message was passed as usage pattern, ie. calling invalid subcommand
such as:

    mytool nonesuch

would result in usage message like:

    usage:
      mytool invalid sub-command: nonesuch
      mytool [options] COMMAND [ARG...]

    [...]

Mostly for purpose of documentation.

Shellfu v0.10.4+ will use the newer format.  This does not justify
hard dependency change, as no known functional components rely on the
version; only thing that uses it is sfdoc to display module version in
man page footer.

Turns out this was not a good idea as it would too easy to trigger.
If a saturnin sub-command was called from within itself (or another other
sub-command), the $SATURNIN_CONF_PATH computed earlier would just double,
leading to unwanted behavior of saturnin__conf_find(), which would find
items twice.

The original problem should be adressed another way; the testing case
be covered by either writing tests on a lower level; eg. unit tests
and use saturnin__conf_find() or saturnin__conf() without forking.

Another solution on part of Saturnin could be to introduce different
variable (e.g. SATURNIN_CONF_DIRS) for values computed by launcher
and keep $SATURNIN_CONF_PATH just for user.

This allows prepending config locations to Saturnin.  This should be
normally used only in cases of staged installattions, such as in sanity
tests.

A less intrusive replacement for _ls_sc subcommand

New variable SATURNIN_META_HELP can be used to control what happens when
user calls the meta command with `--help` argument.

conf is Saturnin's internal command to access common configuration.  It
could be, in theory, useful for end-user to investigate the configuration,
but they would already need to know how it works and which configuration
keypaths or sections they want to look at.

Bettter hide it; it's not worth for the potential confusion.

Note that the command could actually even be removed one day since
internally it's much more efficient to use saturnin__conf().

Only print tagline if defined (similar to codename); do not make it up
with silly string.

Also we can do away without any local variables *and* very safely inside
79 character width recommendation.

eval was little bit too much.

This was always intended; sub-commands starting with dedicated prefix
is the mandatory convention.

As recommended by Shaturnin style guide:

    https://github.com/AloisMahdal/shellfu/blob/master/notes/style.md

As recommended by Shellfu style:

    https://github.com/AloisMahdal/shellfu/blob/master/notes/style.md

This should be useful for cases when a sub-command wants to maintain
non-INI config locations.

The related functionality is stable already and the path is easy to find
out using package manager.

Move satcmd to other repo and distribute saturnin as a stand-alone
shellfu library.  Users can import just the library instead of
embedding it inside their source tree, which enables them to delegate
part of the job to package manager.

We're scratching right ear with left hand...

Absence of quotes breaks queries with spaces.  We're already taking care
of files (implicit or given on command line).

Will make code less ugly at places.

Be nicer to people who get help by trial and error.

The new Shellfu brings some large changes.  Among what touches us
directly:

 *  Most global variables were renamed (removing SHELLFU_* prefix).

 *  inigrep API has been revamped and the file merging/guessing
    feature has been dropped; it now belongs to us.

subcommand (binary) and its arguments are both already is debug-shown
inside saturnin__runsc; cases when that does not get called are normally
not interesting.