For better OBS workflow, it's best if archives are
treated as untracked files.

The package_version() function returns current build information.
Removed the version module instead of fixing, as it's being obsoleted.

Temporary directory generated by code coverage measurement.

Our Makefile required >= 2.6.4 for some time already.
It's pretty straightforward, except for zonefile.lua.in -> zonefile.lua

Let's not mix daemon and client files as client might grow to multiple
files in future. This will also help with upcomming changes to packaging
scripts.

I moved the test files to module directories because it allows
vendoring of whole modules including tests etc.

The test environment provides convenience functions and produces
test output in TAP format. Ideally all tests should use a common
format, so that CI can parse it provide better test output on PRs.
It seems like Gitlab CI doesn't support anything yet, but there
are two sort-of standards supported in CI tools - TAP and JUnit.
I chose TAP because it's easier to read for humans, cmocka supports it,
and it should be easier to adapt Deckard. There are also tools to
convert TAP into JUnit XML file.

Also added more tests for global functions and variables, and the
test tool now also tracks coverage (if `luacov` is installed).

... and generate files instead of including them.

All either generated by the build system or some "standard tools".

All either generated by the build system or some "standard tools".

and set libknot_SONAME and libzscanner_SONAME as lua literals.

Remove now obsolete libpath lua function - use find_soname from
platform.mk to define <arg>_SONAME, add lua_pushliteral to
daemon/engine.c and add -D to daemon/daemon.mk for any new library
loaded from Lua.

This is a fully-socket-activated knot-resolver service that can run as
a non-priivleged user named knot-resolver.

this module is superseded by http module, removing

amalgamated build concatenates all files into a single .c file to
allow compiler see all symbols and produce possibly smaller code.
for binary distributions this is what you want, as it's faster but
may consume more memory during compilation.
it however cannot do incremental builds.

also some cleanup and version bump to Q2