Make a bunch of incompatible changes to the PoolCounter.

Make a bunch of incompatible changes to the PoolCounter.
It wasn't finished, so it's not a big deal.

* Use the term workers instead of threads, which fits better for a multiserver setup.
* The API is now more accurate for our goals (I hope).
* Add support for using the parse from another worker.
* Use child classes instead of array callbacks.
* The daemon is written in C using libevent instead of python using twistd.
* The hash function used is that of Bob Jenkins, with files hash.c and hash.h directly copied from memcached 1.4.5
* Although similar in a few aspects to memcached assoc.c hash table, this is a different hash table implementation. Most important:
** The usage of a double linked list in the hash table.
** Growing is not performed using a maintenance thread. Since the entries are shortlived, it just waits for the old hash table to disappear.
* Note: valgrind 3.5.0 (2009-8-19) does not support accept4 (added in r10955, 2009-11-25). In the meantime you need to use HAVE_ACCEPT4=0 for running with valgrind (as you would need for a non-linux system).
* Sending SIGUSR1 to the daemon gracefully restarts it. The maximum limits will be doubled until the old instance finishes (ie. all its client connections expire).
* Do not try to test it with instances calling an ?action=purge They will serialize on the "UPDATE  `page` SET page_touched" query instead of being serialized by the PoolCounter.
* The workers parameter is not stored by the poolcounter. It is expected that all requests with the same key will also have the same value. A reduction in new entries will not take effect if that number is working (not even when they end, if there are waiting entries). But an increase will increase throughput even for old queued requests.