Refactor the callback part of an event into its own event_callback type

This shouldn't have any visible effect, but it's necessary or
advisible for a few changes and cleanups I would like to make,
including:
   * Replacing the deferred queue with a type that works more as if it
     were an event.
   * Introducing a useful "activate this on the next round through the
     event loop" state for events and deferreds.
   * Adding an "on until further notice" status for events, to allow a
     saner win32-hybrid approach.
   * Eventually, making all user callbacks first-class things with
     event-like semantics.
Remove the unused bits from EVLIST_ALL
Add "active later" event_callbacks to supersede deferred

An event or event callback can now be in an additional state: "active
later".  When an event is in this state, it will become active the
next time we run through the event loop.  This lets us do what we
wanted to with deferred callbacks: make a type of active thing that
avoids infinite circular regress in a way that starves other events or
exhausts the stack.  It improves on deferred callbacks by respecting
priorities, and by having a non-kludgy way to avoid event starvation.
event_base_assert_ok: check value of event_active_count for correctness
Replace deferred_cbs with event_callback-based implementation.
Replace more deferred_cb names with event_callback
New event_get_priority() function to return an event's priority
Add a bufferevent_get_priority() function
Make event_base_getnpriorities work with old "implicit base" code
Give event_base_process_active a single exit path
Restore our priority-inversion-prevention code with deferreds

Back when deferred_cb stuff had its own queue, the queue was always
executed, but we never ran more than 16 callbacks per iteration.
That made for two problems:

1: Because deferred_cb stuff would always run, and had no priority,
it could cause priority inversion.

2: It doesn't respect the max_dispatch_interval code.

Then, when I refactored deferred_cb to be a special case of
event_callback, that solved the above issues, but made for two more
issues:

3: Because deferred_cb stuff would always get the default priority,
it could could low-priority bufferevents to get too much priority.

4: With code like bufferevent_pair, it's easy to get into a
situation where two deferreds keep adding one another, preventing
the event loop from ever actually scanning for more events.

This commit fixes the above by giving deferreds a better notion of
priorities, and by limiting the number of deferreds that can be
added to the _current_ loop iteration's active queues.  (Extra
deferreds are put into the active_later state.)

That isn't an all-purpose priority inversion solution, of course: for
that, you may need to mess around with max_dispatch_interval.
Add an event_base_loopcontinue() to tell libevent to rescan right away
Remove unnecessary code in configure.in.
Be more clear that LEV_OPT_DEFERRED_ACCEPT has tricky prereqs
Add caveat to docs about bufferevent_free() with data in outbuf

Based on libevent-users thread wtih Alexander Klauer
Make it more clear that NOLOCK means "I promise, no multithreading"
Merge pull request #54 from rosslagerwall/configure-dup

Remove unnecessary code in configure.in.
check for arc4random_buf at runtime, on OS X

(Tweaked by nickm: Fix up the arcr4andom_buf OSX hack so that the
fallback case isn't compiled into the code when we have
arc4random_buf() and we are not on OSX.  Also add a comment
explaining what's up.)
Merge remote-tracking branch 'origin/patches-2.0'

Conflicts:
	evutil_rand.c

Had conflicts with _EVENT_ -> EVENT__ change.
Correctly check for arc4random_buf

Apparently it's necssary to do an explicit comparison with NULL here.
This also gets rid of a compile warning