It has no effect in subcommands otherwise.

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

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.

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

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.

(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.