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.

Use of `[roots]` in `[tokens]` is tricky, because final value of a
`[roots:foo]` will "silently" depend on DESTDIR, while DESTDIR is
only known during install time.  On the other hand, `[tokens]` are used only
during build time.

In other words, YOU CANNOT RELY on the value of keys in `[roots]` to be
consistent.  For example, consider root:

    [roots]
        foo = /bar
        qux = [ENV:PREFIX]:/quux

`[roots:foo]` will be '/bar' at build time, but "$DESTDIR/bar" at
install time, and `[roots:qux]` will be "$PREFIX/quux" at build time,
but "$DESTDIR/$PREFIX/quux" at install time.

Just about only case when you might want to use it is mentioning it in
a document, when you want the value to be rather "standard" than
"correct", while you still want to respect PREFIX.

So let's not lead new users directly into that rabbit hole.

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

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.

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.