Overview of changes:

 *  Fix timestamps compatibility with  older git

    Git v1.7 does not support the unix time format, but `%ct` should be
    at least roughly equivalent.

Turns out that git v1.7 does not support `--date=uni`, but `%ct` should
be roughly equivalent.

Overview of changes:

 *  Fixed up time tags.

    First, the choice of hexadecimals turned out as wrong: hexadecimals
    end up sorting in strange ways, at least in version contexts.  The
    format was changed to '+%Y%m%d%H%M%S` (eg. `20180511171502`).

    Second, 'ctime' value for MKIT_TTAG was added, which is the same as
    'btime', but represents commit time rather than build time, so it's
    more deterministic---for that reason it's now also the new default.

Hexadecimals were used to save few characters, but it turns out that
while lexical sort should be fine, in version modes they do tend to
sort in strange ways (eg. `t5af5e80a < t5af5e800` in rpm).

Overview of changes:

 *  Added timestamp to dirty and devel builds

    Some installers (eg. very old version of yum) will make it hard to
    force arbitrary version of build.  This makes quick development
    work harder: you want to be able to reinstall build after small fix,
    but the pesky old yum will keep refusing it.

    This is solved by inserting a time-based tag into the build data,
    For example, making a build from branch 'foo', instead of version like

        0.0.1+foo.g1cf454d

    you will get

        0.0.1+t5af43362.foo.g1cf454d

    where the '5af43362' is based on unix timestamp, so it's guarranteed
    to sort later than the last time (while 0.0.2.anything will still
    sort even later).

    This does not affect clean builds and can be turned off by setting
    MKIT_TTAG to 'none'.

 *  Small readability improvements

Helps ensure that a later devel build will install over older one.

When decoupled from context of exit status, 0 and 1 can be confusing.

Overview of changes:

 *  Fixed bug in macro expansion

    In last versions, multi-line macros were added, but expaning
    multiple macros *per line* stopped working.

 *  Fixed comment removal being too hungry

    Comment removal filter would actually remove any line that merely
    *contained* hash sign.

 *  Codebase maintenance

Overview of changes:

 *  Renamed `[tokens]` section to `[macros]`

    "Token" is not the right word and might be confusing in some cases.

 *  Added support for multi-line macros

    If a macro expands to multi-line value, line containing macro
    reference is expanded by repeating it with each value line.
    This allows for assignments such as:

        [foo:rpmstuff]
            __FOO_REQUIRES__ = foo-libs
            __FOO_REQUIRES__ = bar

    and source files:

        Requires: __FOO_REQUIRES__

    expand as:

        Requires: foo-libs
        Requires: bar

 *  Added support for rudimentary INCLUDE directive

    Useful for development kits: you can include other
    file as basis for mkit.ine.

    The functionality is very limited, though: only one file can
    be included and only one level of incusion is supported (ie. the
    included file may not include yet another file).

 *  Improved debug_var() by using declare builtin

    Array variables will now be shown with reasonable syntax (on most
    Bash versions, anyway).

 *  Codebase maintenance and smaller fixes

Note that v0.0.30 was broken but some installations might exist so we
better skip the version.

Overview of changes:

 *  Fixed caching and versioning logic

    The logic used to get essential versioning info and retain it for
    git-less installs was due to rewriting; it's been simplified and
    cleaned up.

 *  Cleaned up formatting of SPEC file template from stub

 *  Codebase maintenance

Essential fact.sh functions git_lasthash() and semver() have been updated
so that they explicitly depend on git or fail, ie. forget about the cache.

Previously git_lasthash() would try to use cache or fail, while semver()
would try to use cache or rely on mkit.ini, which in turn had to be hacked
by dist() in order to make git-less targets expand version correctly
(with build data, eg. `0.1.2+ge1f4a77.dirty`).

The old code was guilty of four sins: inconsistency (git_lasthash()
vs. semver()), side effects (semver() would actually write cache),
hidden dependencies (both actually relied on functions from mkit.sh)
and unnecessary complexity (speculative $version use in semver()).

New code remediates all of these by making both functions just do their
job (ie. get data from VCS).  Places that did benefit from the silent
caching are served by __cached() function created for this purpose.

These were useful when writing, but it's better to keep rules simple,
ie. newlines only between `case`s or around  long `if`s.

Fields are separated according to relation: first paragraph has fields
referring to *project* and *source code* (we're not distinguishing among
these two); fields in the second on refer to *package*.

Summary, VcsBrowser, License, Source0, BuildArch... all clearly refer to
source code--much more than the resulting package.

Line-based list syntax makes lists easy to extend without creating
commit noise.

Overview of changes:

 *  stub will generate 'install' (not 'PACKAGE'.install) list file

    The other format is necessary for multi-packages.

 *  Removed override_dh_usrlocal from generated debian/rules

 *  Removed extra newline from generated README.md

 *  Added URL to generated specfile template

 *  Reformatted whitespace in generated specfile template

 *  Fixed typo in MKIT_STUB_README.md

PACKAGE.install is only necessary in case of source packages that build
more than one binary packages.

Two newlines *before* (2nd+) heading, one newline after.

Overview of changes:

 *  Fixed issue that would break release

    Releases with many commits or many changed files can produce 'Bump
    version' message so long that it would trigger OS command line limit.
    This risk has been mitigated by ensuring the message is read from
    file instead of git argument.

 *  Added "SRC" mode to preserve file modes from repository

    Sometimes the mode scheme is not easy, so having mode to apply to
    whole group is not plausible.  Setting group mode to a special value
    `SRC` will cause MKit replicate the mode from source (repo or
    tarball).

 *  `stub new` will produce "nice" mkit.ini right away

    Previously, re-formatting of mkit.ini would work only in update
    mode; now it's nicely re-formatted on creation.

 *  Fixed formatting of INI files

    If value in INI file contained space, formatting would break it up.
    This is no longer the case.

 *  Cleaned up specfile template stub

    New specfile template now does not contain tabs, has fields grouped
    in more logical way, and omits BuildRequires, which was not all that
    correct anyway.

 *  Improved README.md

If release contains many commits and/or those commits contain many
changed files, the command line could grow past OS limit.  Using stdin
avoids this.

Not just on update but also on creation.

Project-related, then codebase-related, then (binary)-package-related.

If sources are built using `dist`, `rpmstuff` or `debstuff`, current
version of MKit does not actually require git--all that is necessary
should be cached in the tarball anyway.

Regarding coreutils, they are part of essential set on most
distributions; on those, one should actually refrain from specifying
them.