Although normally we prefer to sat "result must look like oracle",
that is, have result on RHS, and oracle on LHS of a comparison, with
udiff this produces far more readable result, e.g.:

    --- oracle/try_import_fn.new
    +++ result/try_import_fn.new
    -foo

if foo was expected but is missing,

    --- oracle/try_import_fn.new
    +++ result/try_import_fn.new
    +bar

if bar came unexpected.

shellfu-get (whose only job is to print one of hardcoded strings depending
on $1) and shellfu.sh should be as light as possible.  Most of this code
is only useful (and intended) for library exploration, which is domain
of shellfu-doc.

A neat side-effect is, that in its new home, we don't have to be so
fussy about performance and footprinting, so we can afford luxury such
as putting code into functions and documenting them, using $1 for first
argument, using shellfu libraries(!)...

Needless to say, this is an incompatible CLI change (or it would have
half the effect), so we take the opportunity to re-do the CLI to match
the new home.

Remove '()' decoration from $caller internal variable. Decorations are
matter of presentations; at this level the brackets are only confusing.

To decide whether a caller is main script or direct descendant thereof,
called main(), use negative index of the stack array FUNCNAME (0 in first
case, 1 in the second).  To signal that to the `_pretty_*` plug-ins,
use a dedicated boolean.

This also accounts for cases when a main() function is declared somewhere
else than in the main binary.  Older code would simply assume (based
on the name being "main") that it's called from main binary and rewrite
$caller, possibly causing confusion.  Now, only the originally intended
special cases behave specially.

This is simply impossible; debug_pipe is wrapper around debug which is
identified soon enough, so "debug_pipe" can't be assigned to $frontend.

Also, _pretty__get_frontend() will never return bracket-decorated
function name.

Without -r, sequences like '\t' are translated, which we basically never
want.

The grep throws away all empty lines, no matter if SHELLFU_DEBUG is on
or not.

This seems as terrible idea and I can't find out what wass the reason for
that.  (I wonder why everything is not broken due to this; most probably
because nobody really uses debug_pipe.)

The exclusion criterion would be true for amy frontend just if debug
was on and the caller fit SHELLFU_DEBUG_EXCLUDE.  That is, even warnings
and thoughts from the caller would be muted!

In fact, it's frontend that matters; only debug frontend should be
considered for exclusion.  OTOH, we don't need to check SHELLFU_DEBUG as
debug frontends already give up ASAP if that is not set.

We also need to move the frontend rewrite sooner for this to work.

It's rather useless in load-time, since the environment is often
tailored since then (e.g. SHELLFU_PATH is the most obvious example).

By far most realistic use case is import; even those related sub-commands
are always used along with import anyway.

... for better readability and extensibility.

According to best practice (leads to cleaner code).

Overview of changes:

 *  Added data for Debian packaging
 *  Significant infrastructure updates (MKit v0.0.10)
 *  Minor tweaks

Mostly ugly (at least how lintian sees it) but first working version.

pretty.sh assumes that mkusage is always called from a function named
`usage()` and manipulates $caller based on that.  For subcommands,
though, the convention is based on name of the binary anyway, so we can
easily circumvent that limitation.

 *  Added ability to mute debug output per module and/or function
 *  Renamed shellfudoc for consistency with rest
 *  Improved docs
 *  Improved Test suite
 *  Improved packaging

Have it pretend and demonstrate situation when two modules are used,
both following shellfu naming conventions.

Hopefully the last batch...