*  Split into functions as appropriate;
 *  add docstrings;
 *  reduce redundancy;
 *  run everything in C locale (=> update oracles),
 *  add subtest boundaries to output.

Instead of creating SemVer name on-premise, it will be hard-coded inside
the tarball

Now we can keep examples as a "real" shell scripts, taking advantage
of ability to test them or edit them with proper syntax HL.

Setup will now automatically insert them and indent properly as code.

Small drawback is that we cannot build manpages separately, but since
all building is to be trivial this is not a big deal.

...to better demonstratr new merging capabilities

Strict mode now preserves also comments, which makes sense when iniread is used only
to merge ini files verbatim.

It's not specifed yet which is to be picked, but as FFOO_INI_PATH is now
respected properly, it's more intuitive to pick the last--the last item
on FFOO_INI_PATH wins, which is similar to how PATH works.

Using empty element results in checking "/file.ini", which is not what one
would want.  (One can always explicitly provide path as argument.)

Increase readability: decrease complexity of the build function and
preserve wandering off too much against 80-char "buoy"

Make it easier to share &  sync installer code across projects from the
same family.

While still non-intruding (only one line per one real world action)
(un)instalation could be more talkative.

Basically as a skeleton to see if this form could be used widely.

Now --version-patch does not print metadata, and -proper and -meta have
been added to filter particular part ("proper" semver field w/o
meta-data, or meta-data only).

If not in git (e.g. unpacked tarball), trust the tree and just use
VERSION from config.mk.

Otherwise, take newest tag, and if HEAD is tagged, use that tag
(without the initial "v").  If HEAD is newer, form build meta-data
field from shortened commit hash; furthermore if tree is "dirty" (i.e.
has some files modified, add ".dirty" to the version number.

For example, you just tagged the HEAD with v1.0.1, the version
number is therefore

    1.0.1

Now you edit a file.  At this moment if you build the project, the
version will be

    1.0.1+dirty

If you add + commit that change, the "dirty" has name now:

    1.0.1+ga34f8c

but now if you edit a file and re-build, you get "dirty" again:

    1.0.1+ga34f8c.dirty

In other words, anytime you see "dirty" in the version info, you know
that the tree was manually modified (which could mean anything from
fixing a typo to completely changing the code).

If there's only g??????, then the code has been modified as well, but at
least you may have reference to the actual tree.

At any rate, any version with any meta-data is purely internal and
should never be used for comparison (your tests should not rely on
version string comparison).

Similar to grep or test, 1 is reserved for "no", 2 is used for
"incorrect use/syntax"