Folow-up to 37b5db9 and 9c94a46.

Source the setup/cleanup code so that it can be used to prepare
environment.

Disadvantage is that the files will need to be in Bash (ie. effect of
commit 4eb772d is negated), but that should not be problem as the use
of subtest.sh already implies that Bash is used.

After all, one can always easily run other program from these files.

Add examples, simplify sections and ordering of topics.

Inside function that gets called during debugging, it gets in the way
pretty fast.

Hopefully this is ledd confusing than calling 'toes' something that
represents most of the original string

This seems too hard to support safely, and the advantages are minimal as
most cases will be possile to solve by wrapping the builtin into a
function.

Turns out that get_version and release.sh strategy do not agree
very well on this, which may end up as version comparison problem.

SemVer 2.0 says that pre-release versions go before the associated
versions, that is, 1.0.0-blah goes before 1.0.0, and at the same time
remove the compatibility guarantee.  This means that if pre-releases
are needed, we will probably need to change both PRERELEASE and VERSION,
which is not what was expected when writing release.sh.

For now, the safe thing is to remove PRERELEASE altogether.  If we ever
need to do a pre-release, we will re-verify if it works properly; until
then, build meta-data give us enough luxury.

The caching does not clean up, and is mostly unnecessary since Linux
will cache the file anyway.

Reserve PROJNAME for a "human-readable" name.

Colon in STAGE will most probably confuse matcher and lead to corrupt
version data.

This should give better hint if built from a feature branch

For now the spelling has been decided "Fastfoo", not "Fast Foo", or
"FastFoo".

These have been moved to saturnin