Remove mon_loop ev_child watcher in plugin_extmon

It was always wrong to do this here, it just happened to
work because mon_loop == def_loop (which will shortly no
longer be the case!) and no other plugins were also spawning
and watching children.

We're catching and logging the death in the pipe reader anyways,
so there's no true loss of reporting.  We will gain a zombie
now on these deaths, but that's ok - it's only ever one
process per daemon, and if anything it further highlights
the problem.  These children should never die unless there's a
code bug involved, and we never try to respawn them if they do
(because we can't in the chroot case).
Remove loop argument from plugins' pre_run callback

It was never wise to expose the main thread's default
ev loop this way.  No plugin is currently using this facility,
and the default loop of the main thread is going away in the
near future.  Plugins that really need to do complex
maintenance tasks can spawn their own side-threads the
way that plugin_geoip does.
Restructure threads/loops/sighandlers

Old scheme:
   monitoring + statio use default ev_loop in the main thread of
   execution, alongside the global signal handlers for SIGHUP,
   SIGINT, SIGTERM.
New scheme:
   monitoring + statio use a separate mon_loop in their own
   separate thread.  There is no default loop (or any loop) in
   the main thread.  The only runtime task for the main thread
   is signal-handling, which is accomplished via sigwaitinfo().

Also, all libev io/timer collection delays were removed - they
don't really make sense the way they were being used, they
just add latency.

This seems to reduce up startup/shutdown latency a bit (enough
to cause a large drop in testsuite runtime), but more importantly
it eliminates the chance of interrupted system calls screwing
with anything in the monitoring/statio code, since all of our
non-main threads run with all signals perma-blocked.