Replace pipe-based notification with EVFILT_USER where possible

Sufficiently recent kqueue implementations have an EVFILT_USER filter
that we can use to wake up an event base from another thread.  When
it's supported, we now use this mechanism rather than our old
(pipe-based) mechanism.  This should save some time and complications
on newer OSX and freebsds.
Work-around a stupid gcov-breaking bug in OSX 10.6

This only affects the unit tests.

Fix found at http://rachelbythebay.com/w/2011/07/12/forkcrash/
Move use_monotonic and friends into event_base

The use_monotonic field used to be a static field set up at library
setup.  Unfortunately, this makes it hard to give the user a way to
make speed/accuracy tradeoffs about time.  Moving it into event_base
should let the clock implementation become configurable.
EVENT_BASE_FLAG_PRECISE_TIMER indicates we want fine timer precision

There are a bunch of backends that can give us a reasonably good
monotonic timer quickly, or a very precise monotonic timer less
quickly.  For example, Linux has CLOCK_MONOTONIC_COARSE (1msec
precision), which is over twice as fast as CLOCK_MONOTONIC.  Since
epoll only lets you wait with 1msec precision,
CLOCK_MONOTONIC_COARSE is a clear win.

On Windows, you've got GetTickCount{,64}() which is fast, and
QueryPerformanceCounter, which is precise but slow.

Note that even in the cases where the underlying timer claims to
have nanosecond resolution, we're still not exposing that via
Libevent.

Note also that "Precision" isn't the same as "Resolution" or
"Accuracy".  A timer's precision is the smallest change that the
clock will register; a timer's resolution is the fineness of its
underlying representation; a timer's accuracy is how much it drifts
with respect to "Real Time", whatever that means.  (Terms and
definitions from PEP 418.)
On Linux, use CLOCK_MONOTONIC_COARSE by default

You can make it use CLOCK_MONOTONIC again by setting the
EVENT_BASE_FLAG_PRECISE_TIMER flag in the event_config.
Implement a GetTickCount-based monotonic timer for Windows
Merge branch '21_choose_monotonic'
Note that make_base_notifiable should not be necessary
cancel the probe request when the server is freed, and ignore cancelled probe callbacks
remove redundant DNS_ERR_CANCEL check, move comment
Merge pull request #52 from ghazel/20_evdns_probe

cancel the probe request when the server is freed, and ignore cancelled probe callbacks
Merge remote-tracking branch 'origin/patches-2.0'
Refactor event_persist_closure: raise and extract some common logic
If time has jumped so we'd reschedule a periodic event in the past, schedule it for the future instead

Fixes an issue reported on libevent-users in the thread "a dead
looping bug when changing system time backward". Previously, if time
jumped forward 1 hour[*] and we had a one-second periodic timer event,
that event would get invoked 3600 times.  That's almost certainly not
what anybody wants.

In a future version of Libevent, we should expose the amount of time
that the callbac kwould have been invoked somehow.

[*] Forward time jumps can happen with nonmonotonic clocks, or with
clocks that jump on suspend/resume.  It can also happen from
Libevent's point of view if the user exits from event_base_loop() and
doesn't call it again for a while.
Merge branch '20_periodic_event_overload_v2' into patches-2.0
Merge remote-tracking branch 'origin/patches-2.0'
Shave 700 msec off the persistent_timeout_jump test
Split long lists in Makefile.am into one-item-per-line
Split out time-related evutil functions into a new evutil_time.c
Split out time-related prototypes into time-internal.h