Also break overlong lines.

when doing fast retransmit, each address may be
contacted 1-N times, but previously only cumulative
RTT was tracked for the NS that sent the answer.

now the approximate query start time is subtracted
from cumulative RTT to give an idea how long it
took since the query was actually sent, and all
the NSs that didn't respond within their retransmit
windows are penalised too

the e638f9fb introduced deduplication
for queries over UDP, the idea is to track same queries and answer
only once, however that introduces both constant processing and
memory overhead and could break clients who count packet loss
by queries sent/received. disabling for now.

* in the begin() layer, the incoming query is
  exposed as req->qsource.packet, it is invalidated
  after begin() and should not be modified
* the destination address (local interface) is
  also tracked for filtering purposes

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.