gdnsd.pod: simple fixups
gdnsd.pod: admin_state docs
Fix various admin/monitored state output printing

  log messages for admin_state make a little more sense now
  html/csv/json output over http cleaned up so they all have the
same consistent columns of data with the same meanings (just
current state and real state, which are often the same).  Forced
states are indicated by an "!" suffix on the current state, and
a change of color in the html case.
Fix admin_state testsuite to match dbf9efbe
add __unreach_builtin support under clang
fix the builtin_unreachable check for clang
Only use EPROTO if it's available.

This unbreaks the build on OpenBSD which lacks EPROTO.
Merge pull request #78 from jasperla/eproto

Only use EPROTO if it's available.
A few minor build/install updates and doc fixes
typo fix
extmon no longer needs paths-priv
Fix djbdns zone data parser crash on malformed input

from fabled, Fixed #79
Fixups for gdmaps reload thread cancellation.

(Some of this seems a bit pedantic, but it proved necessary
when testing against musl libc).
New config option 'max_edns_response'

Some clients apparently default to advertising a 4K edns0
buffer size for UDP response traffic, which isn't well-suited
to use on the public Internet.  Some rare datasets may actually
have data this large for irregular usage of the DNS to transport
other data.  The intersection of these two things can cause
problems.

This option caps the buffer size advertised by the client to
a configurable value on the server, so that we don't try to
send edns0 UDP responses larger than this value, instead
trucating and falling back to TCP.  It defaults to a sane
value of 1280, which is very unlikely to fragment on the public
Internet, yet still offers more than twice the packet size
of traditional UDP DNS, and more than enough for normal,
non-DNSSEC responses in most cases.

See discussion here:
https://groups.google.com/forum/?fromgroups=#!topic/gdnsd/S6CuZj18nVQ
Fix sizing issues with max_edns_response, etc

Obviously, for the testsuite to do its job max_edns_response
needs to have the same upper limit as max_response, and
needs to be set for some tests.

Along the way it was noticed that the docs and code disagreed
on the upper limit of max_response.  64000 has been the correct
and functional value for a long time, and the docs have been
incorrectly stating that it was 62464.  The limit was raised
from 62464 to 64000 back when the DNSCurve code was removed
prior to the 1.6.0 release.
Remove gdmaps_destroy code completely

This code was only ever for detecting memory leaks
in debug builds, and was also executed by the libgdmaps
testsuite.  However, it raises complex issues that
cause lockups and/or segfaults on some (arguably
very broken) architectures, so it's just not worth
it.
add missing gitignore entry
testsuite was missing accum for udp_recvfail
Misc docs updates
minor doc fixups