I have no idea what I was thinking when I added the pipe there...

Although pretty, this way of initializing ffoo must go since it's
not possible to protect it with a working `|| exit 3` clause.

Problem is that bash will create the pipe no matter if the ffoom call
eventually succeeds or not, so in case ffoom is not ready we end up
sourcing and empty file--which always succeeds.

Use this parameter to prepend directory to module search path.

If user wants to interpret the SemVer they can use one of modules
available for this purpose or do their own "cutting".

to easily test out documentation for currently developed library.

which is somehow better than "random" order.

Use of `;&` instead of `|` yields the same behavior, but is much easier
to read if number of alternatives is longer.

 *  Re-use code provided by `-e` as function exit status.

 *  Default to FFOO_EXITS_USAGE, i.e. 2.

 *  Add -k as shorthand for `-e 0`.

 *  Update and enhance docstring.

`echos()` is implemented using `printf` with format argument containing
one `%s` and newline.  `printf` behavior is to repeat the format for
any excessive arguments, so that we may end up with multiple lines:

>     $ printf -- "%s\n" 1
>     1
>     $ printf -- "%s\n" 1 2
>     1
>     2

Since use of `"$@"` is often recommended as default, frontend call like
`think "args: $@"` are to be expected.  This way arguments are split
automatically,  however, traditional `echo` would normally join them back
to one line.  It's more intuitive to have the same behavior by default.

Using `"$*"` in __echo_args results in joining all parameters back to
single line, resulting in printf calls similar to this:

>     $ printf -- "%s\n" "1"
>     1
>     $ printf -- "%s\n" "1 2"
>     1 2

Note that user can still use `-l` argument to switch to __echo_lines
should they really want to have each argument printed on a separate line
(but that's a different story).

Do not touch world on importing, use explicit function for empdir
creation.

git-describe will prefer annotated tags, git-log has much more straightforward solution