Turns out that leaving this to saturnin__conf_mkpath() is not so good
idea.

There's no real need to list every file.

SHELLFU_PATH brings more harm than good; developers are encouraged to
put their private modules to regular shellfu path (in most cases
/usr/share/shellfu/include-*) and use SHELLFU_PATH only for testing.
It's a bit simpler (gets rid of one whole token) and has the advantage
of exposing the library to sfdoc.

MKit (as of 0.0.25, and probably for long time in furure) ignores tokens
not defined in mkit.ini, so app developer has to either define it or
their users will see errors on every `app --help call`.

This way we can remove the need to define yet another token.

With most Saturnin setups there won't be anything else in bin anyway.

Require merge to 'master' prior to version bump and update 'last' after
release.

Overview of changes:

 *  Added build-time tests

    Saturnin Demo now demonstrates how to add tests using TFKit and
    enable them on both Fedora and Debian.  (This means dependency bump
    to Saturnin 0.4.8, since overriding SATURNIN_CONF_PATH was not
    available, which made config-related tests hard in staged
    installations.)

 *  Enabled overriding path variables in launcher

    Launcher used to hard-code all environment variables.  This made
    testing in staged installations hard.

 *  Updated meta-data and templates

    An amount of smaller changes has been done to improve readability,
    maintainability and overall looks of packaging meta-data.

This requires newer Saturnin version in order to avoid bug where
SATURNIN_CONF_PATH environment variable would be ignored.

Several changes to improve maintainability, readability and style of
packaging meta-data:

 *  Use more maintainable syntax in templates.  That is, more MKit macros,
    line-based lists, etc.

 *  Use Markdown for LICENSE.

 *  Use normal case (don't YELL) in application name.

 *  Use only spaces to align spec file.

 *  Use version ranges for SemVer dependencies.

 *  Sort %files section.

 *  Use shorter version level (0.y vs 0.y.z) in ranges where possible

 *  Move MKit compatibility directive to bottom (which actually changes
    the compatibility level to 0.0.24 as older MKit had a bug that
    prevented seeing the directive near the bottom.)

Having them strictly hard-coded makes it difficult to write system tests
test in staged install scenarios.

Overview of changes:

 *  Excluded inigrep as well as saturnin itself from normal debugging mode

    One has to call -D|--full-debug to see the gory inigrep/saturnin stuff.
    Normal debug is supposed to be used for things relevant to
    subcommand scripts.

 *  Moved to /usr

 *  Added --full-debug and -V to tab completion script

 *  Many code and packaging clean-ups

 *  Updated for Saturnin v0.4.7

 *  Updated for Shellfu v0.10.1

 *  Updated MKit to v0.0.24

It makes a lot of noise that is normally not very relevant to the
application.

They made sense when the script was bigger, now they delimit basically
the whole script.  Also "built part" is not accurate since the part is
not built--it only happens to contain lot of macros.

Saturnin Shellfu module used to be embedded into the repo; now it lives
its own life (we already have it in dependencies).  All the app needs is
meta-command and scripts.

Overview of changes:

 *  Fixed quoting when setting $SATURNIN_CONF_PATH

 *  Replaced complete.bash with skeletal version of itself

    With reasonable version of mkit, the skeleton can be readily used
    without any modifications.

 *  Applied first attempt to be more conformant with XDG standards

    Saturnin-demo now uses XDG paths for cache, local data and config
    data and does it in such a way that respects these values from
    environment variables as prescribed by current XDG.

    Note that not all paths described by XDG are used.

 *  Simplified Saturnin's mkit tokens

    Another step to increase usability of this demo with as little
    modifications as possible.

(Shame I did not see that earlier...)

First attempt to base saturnin paths on XDG paths.

Turns out this is not good practice; the tokens are only used within the
process of building the application so there's no need to qualify them.
Having them qualified in fact adds unnecessary spam when syncing with
the template.