refactor/update path-handling code
Make stats output buffer calculations more-robust

I've gotten one unconfirmed, hazy, private bug report that could
  indicate some kind of problem with the http output code, but
  no reproducibility or details yet...
However, after doing some manual counting and validation, it
  seems to me that there is a possible theoretical bug or two in
  the output buffer sizing for JSON.  I suspect it would be
  difficult for anyone to trigger them in practice.  At the very
  least it would require a very large set of monitored resources
  and almost all of them being simultaneously in the DANGER
  state during JSON output, I think.
In any case, I've patched things up a bit, made the sizing code
  a bit more consistent and robust, and then doubled the final
  size calculation just in case.  The code is still very ugly,
  and hopefully it will become deprecated or refactored at a
  later date when the mini-http-server goes away in favor of
  some other stats-output solution...
Fix gcc incompatibility in a51eb26f

Apparently gcc isn't as smart as clang about what is
or isn't a "constant".  Thanks Travis-CI for pointing
out the issue, I only checked clang before pushing! :)
remove some pointless dead lines
Fix bugs in http stats output network send code

This code just happened to work *if* the entire HTTP message
fit in the buffer in the first writev() call (which would be
the exceedingly common case), but it was horribly broken if
writev() did a partial write, generally resulting in a
neverending loop of broken EV_WRITE events that kills the
stats output thread (but doesn't really affect DNS operations).
Merge branch 'master' into 2.x

Conflicts:
	gdnsd/monio.c
	gdnsd/statio.c