many clients do frequent retransmits of the query
to avoid network losses and get better service,
but then fail to work properly when a resolver
answers SERVFAIL to some of them because of the
time limit and some of them NOERROR. 
it's also a good idea to avoid wasting time
tracking pending tasks to solve the same thing.

* daemon now processes messages over TCP stream
out-of-order and concurrently
* support for TCP_DEFER_ACCEPT
* support for TCP Fast-Open
* there are now deadlines for TCP for idle/slow
streams (to prevent slowloris; pruning)
* there is now per-request limit on timeouts
(each request is allowed 4 timeouts before bailing)
* faster request closing, unified retry/timeout timers
* rare race condition in timer closing fixed

breathe failed to process the typedef thinking
the macro expansion was a function pointer

this is not going to be backwards compatible change, but it will be the first tagged libknot release sufficient for resolver

worker can track outbound requests and if N resolutions want the same
subrequest, only one will lead it and others will be notified when it
finishes

this massively reduces number of outbound requests for
slow/unresponsive/low ttl requests

example:

worker.resolve('cz', kres.type.NS, kres.class.IN, 0,
function (pkt)
	local answer = kres.pkt_t(pkt)
	print (answer:rcode())
end)

This reverts commit 91a2945e.

Conflicts:
	daemon/worker.h

this avoids repetitive allocation/free cycles on load

the TCP allowed parallel processing of multiple requests over
one client socket, however if the client socket disconnected,
it left the running tasks reading from bad handle
now each task takes ownership of the handle until it is finished,
only then it is returned to the loop and closed

* each query is assigned a task
* each task contains request, some primitives and mempool
* worker can process multiple tasks at once and
  offload I/O to event loop

Not finished:

* it depends on icmp/system timeouts, #22
* tcp reads are going to be bad if the messages
  arrive fragmented #21

the worker now creates a resolution context copy,
and keeps it if the query requires iterative queries.
the worker_exec() is now a reentrant function that gets
called with incoming data until the resolution is done,
and it sends the answer

The engine is responsible for central managemento of resources and work
distribution. This allows to spawn multiple loops.

The engine configuration / interface is based on Lua 5.1-5.2, including
a RPC and a simple CLI interface. This is going to be the core of configuration
later on.