As noted in #94, it feels natural to call it like:
``net.listen({net.lo, '192.168.1.1'})``
Also, minor fixes were done in that function and corresponding docs.

if the score is known (and not glued), the retry
rate is <avg(rtt), 250ms>

if the NS score is unknown or worse than 250ms,
it is always retried at this rate

all other servers in the list use default rate

RTT tracking for all targets is also supported,
but no loadbalancing is done based on that yet

timeouts over TCP when <n> first nameservers timeout over UDP as
previously the TCP would connect again to the first and only the
first nameserver in task->addrlist.

This would need to be ultimately fixed in TCP Fast Retransmit.

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

example:

> daf.add 'forward 127.0.0.1@5353'

The missing entry caused some entries to be dear and written to wrong
positions.

The control structure is part of the resolver context.

Use ENABLE_cookies=yes variable to compile functionality.

Cookies are not stored in separate cache.

RFC 7858 explicitly defines an out-of-band key pinning profile as one
authentication mechanism.  It uses the same format for representing
the pin as HPKP does (RFC 7469).

By logging this pin directly upon first use of the X.509 credentials,
we make it a little bit easier for an admin to publish part of a
pinset.

For ideal operation (including preparation for key rollover), a backup
public key should also be provided, but this is not defined
functionally here.