barebones LRU crawler proof of concept

so many things undone... TODO is inline in items.c.

this seems to work, and the locking should be correct. it is a background
thread so shouldn't cause significant latency. However it does quickly roll
through the entire LRU (and as of this PoC it just constantly runs), so there
will be cpu impact.
basic tests + lrucrawler -> lru_crawler
return next item from crawler_crawl_q

... instead of return flags and such.
adjust some comments.
don't waste an item flag for crawler

detect via an impossible item: nbytes/nkey are 0. There're other clever ways
we could do this as well (nbytes == maxint, etc).
crawler reclaims stat
control system

nothing internally magically fires it off yet, but now there is an external
command:

lru_crawler crawl [classid]
... will signal the thread to wake up and immediately reap through a
particular class.

need some thought/feedback for internal kickoffs (plugins?)
notes
optionally take a list of slabs to run against.

lru_crawler crawl 1,2,3,10,20 will kick crawlers off for all of those slabs in
parallel.
command to change the sleep between runs

lru_crawler sleep 1000 - sleeps for one millisecond between runs.
starttime options for lru crawler

-o lru_crawler,lru_crawler_sleep=500 - enable it and set sleep for 500
microseconds.
refactor crawler thread a bit

reduce indentation, shorten the function a bit. also now sleeps after every
inspected item vs after each run through all active slabs.
LRU Crawler command documentation.

lacks autorunning stuff still.
lru_crawler fixups for latest master branch
-h docs for lru_crawler
use do_item_remove in lru crawler

the crawler was saving a few operations by directly freeing an item, but lets
use the normal code path instead. The assert looks to ensure item_free() was
actually called as we expected. Though I guess lots of people don't use the
debug binary...
lru_crawler crawl all

... go crawl all available classes.
make stats-cachedump and flush_all ignore crawler
lru_crawler_tocrawl to limit inspected per run

Since we start from the tail, and some slabs could be many millions of items,
it doesn't always make sense to walk the entire thing looking for data to use.

This could be a lot smarter: say specify a percentage, and it'll only crawl a
percentage of used_chunks for that slab for instance.
fix LRU contention for first minute of uptime

Noticed in benchmarks that memcached was slow for the first minute. ~350k
gets/sec max, then it would jump up to millions/sec.

    if (it->time < current_time - ITEM_UPDATE_INTERVAL) {
current_time starts at 2, which then underflows toward 4 billion, which is
larger than it->time, so all fetches for the first minute require shuffling
the LRU. Which happens under a global lock.

This probably goofed up all short-term benchmarks, and potentially slowed down
high traffic instances which were recently restarted.

Unfortunately this means the tests no longer exercise item_update(), so some
more work is necessary.