We have no tests so TFKit is useless here.

Overview of changes:

 *  Fixed version directive lookup

    mkit.ini would be refused if version directive was at the end of the
    file, while first and last 3 lines is what was supposed to work.

 *  Fixed license argument check

    stub script would ignore license argument due to argument validation
    error caused by refactoring.

 *  Fixed bad grep advice in MKIT_STUB_README.md

 *  Updated own dogfood

I don't know how I came up with that pipe but it's certainly wrong.

Earlier I replaced all checks on $License valiue when I should have
replaced all *but this one*.

Overview of changes:

 *  Rewrote *newstub* as *stub* meta-command, now with update mode

    The script looks promising, let's use the extensible CLI scheme.

 *  Removed sorting from `ini lskeys`

    *stub* can rewrite user's mkit.ini but it does not want to mess it
    up more than is necessary.

 *  User can now override project version with *stub*

 *  *stub* now Respects MKIT_INI environment variable

 *  Fixed problems with LICENSE.md and README.md rewriting in *stub*

 *  Moved MKit version directive to end of file

 *  Improved MKit's own project README.md

It does not work if the body is not trivial and narrow.

'newstub' was not so far to being able to update meta-data based on
existing mkit.ini.  However, in order to keep the CLI sane, it seems
better to switch to meta-command scheme.

For purpose of rewriting user's INI, we don't want to mess it up more
than is necessary.

Not everyone likes v0.0.0.  While it's trivial to change, the other
reason for this is scenario when user just updates (re-builds) the
meta-data.

Not everyone wants mkit.ini in the root.

Being consistent leads to much more readable code.

Try to show user also "why" they might want to do it.

Overview of changes:

 *  Added 'newstub', builder script to help with new projects

    The script is intended to help start up new MKit project by generating
    structure necessary for MKit to work, and instructing user which
    parts to review and how.

 *  Fixed bug when skeletons could be deployed as part of directory

    If directory targeted in [files] section contained .skel files, they
    would get deployed along with built files.

 *  Code refactoring

    Moved global variables to new vars.sh module, improved initialization
    and importing code and added file headers.

 *  Improved patch importer utility

We had to switch to recursive mode so that we can control more precisely
what gets installed.

To minimize code needed to import a module

Overview of changes:

 *  Enabled rpmstuff and debstuff specific tokens

    These can be used to (somewhat hackishly) try to mitigate
    differenceds between distros.

 *  Fixed printing error message to stdout
 *  Fixed broken error message

 *  Big code cleanup

    Only refactoring, but we needed to get up to date with style.

Drop the unnecessary and space-wasting requirement that `do` and `then`
must be alone on line.  It's a thing of the past!

Can be useful in cases when Debian and RHEL/Fedora/... paths differ.

Decouple variable declarations so that each can have docstring.
In case of _relck() we also rename variable $relsrc to a more
context-specific term $oracle.

Where not required, they only add visual cruft.

Probably leftover from slightly different implementation.  There's
nothing to add to the error message now.

In this file we declare lot of globals and source lot of code, and
basically do only that, which makes this check less useful.

Overview of changes:

 *  Added `vbump` and `release` targets, defaulting to Z

Overview of changes:

 *  Changelog will be included in tag annotation message.

    The changelog generated by `vbump_*` target will be included in tag
    annotation message.  The annotation message is meant as release note
    of sorts, so it makes sense to have the changelog there.  (For
    example, GitHub will use the message as release note on Releases tab
    of a project.)

Annotation message is meant as official release note, so including it
there makes sense.

(For example, GitHub will use it to create release note under Releases tab.)