* Make sure newly added events are enabled
* Don't mark callbacks as inactive if they're a persist callback.
Introduce the first cut of the persistent-write event handling, specifically
designed to avoid re-registering for write readiness all the time.

The overview:

* comm_write() will now schedule write-readiness only once;
* .. and ev_write is now a persistent/clearing kqueue note, rather than a
  one-shot event
* Which means it'll fire off a response event every time to socket
  buffer falls below the low watermark
* Since I can't (yet) schedule comm FD events to happen if there's no comm
  event from the kernel, split out the real work into a separate callback.

But!

* This is only lightly tested!
* I really should use the socket buffer write space response from kevent()
  which will tell me exactly how much data I can write, rather than
  trying to write when I may have a busy socket.
This is the wrong place to be re-scheduling for another write()
attempt!
* Don't remove the item from the active queue if it's a persistent event.
* Add a note that we should really squirrel away the 'data' value as it's
  very useful when doing optimistic writes - we know how big (at least)
  the buffer is, so we can choose to do writes up _until_ that value,
  rather than constantly hitting EAGAIN.
Don't be optimistic about writes, at least until I know how big the socket
buffer really is (from the knote above.)

I'm still seeing EAGAIN on writes though. I need to investigate that.
Document how NOTE_EOF works on read.
Commit some initial, untested debug logging code.

This differs from what we did in Squid - here, it's a bitmap that
by definition only has meaning for each debug section that is
registered.

I aim to add a debug de-register method and a debug bitmap parse
and output methods so different modules can have a fully text
representation of their debugging flags.

But, this gets me out of the hothouse with respect to debugging;
now I can register some debug sections and start doing useful
work with it.
Add another TODO item.
Since callbacks can create new callbacks, we need a way to ensure
that we don't get stuck in a loop just scheduling callbacks.

Now that read/write IO doesn't necessarily require a trip through
the libevent routines to schedule, lots of callbacks get generated
to do things.  This has made things .. worse.
Fixed.
Micro-optimise - no need to check the timer list for the next timer
to fire if we're just going to immediately call some more callbacks.