Use CRC32C (on supported hardware) as a hashing function on rel builds

While not as good for a general-purpose hashing function, CRC32C is
very fast when using specific hardware instructions, on quick and dirty
benchmarks, this beats Murmur3 by around 7x.

Hash tables bucket sizes are fixed to 32 now, because the number of set
bits in the CRC32 is used to index the bucket, as a mean to fully
utilize all the calculated 32-bit value.

Benchmark results, for 50000 lookups (using rdtsc) on a reasonably
small hash table with ~100 items:

                Average    Std.dev   Min     Max
CRC32           211.767   3910.211   42.000    874347.000
Murmur3         596.888  68135.718   82.000  15235690.000
Ratio: M/C        2.818     17.425    1.950        17.420

On average, hash lookups are now ~3x faster, and can range from ~2x to
~17x.

(On a side note: stddev is too high; I should redo these benchmarks
using rdtscp or some other pipeline-flushing instructions)
Add loading cache infrastructure

This is loosely based on Guava's CacheBuilder, although much less
versatile and tunable.

Items are reference-counted and evicted after a fixed amount of time
after they've been created, although the policy to evict after the last
time might be another good candidate.

Since this is a loading cache, it knows how to create and destroy the
entries; this greatly simplifies the interface (one just asks the cache
for an item referring to a key, and if it's not there, it's automatically
created).

Read-write locks from pthread are used in this implementation, but this
might move to something that scales better, such as RCU or similar
technique.

This isn't used right now, but the idea is to have this be transparent
for all the handlers.  Also, this haven't been extensively tested.  We
might hit a few bugs whenever lwan switches to this infrastructure, but
you're not relying on lwan, are you?
Make hash bucket size untunable

This simplifies the hash interface a little bit.
Wire the new caching infrastructure to the static file serving handler

There's still lots of work to do to make the caching layer transparent,
but this is an important step in making sure the loading cache is
actually working.  From initial testing, it is, and it rocks!

Server boot time has considerably decreased as file information is
loaded and cached on demand (and pruned after a while to keep memory
usage low).

The job thing should be revisited, though. It is currently performing
way too many unneeded system calls; I might use timerfds and epoll for
it later, but right now a thread that calls sleep(1) seems to do the
job fine.

Directory watcher is gone, as we don't need to use inotify to know when
a file information has changed.  The cache will prune old data and if a
new request comes along, it will be automatically updated.  Not sure if
this is the best approach, but with 5 seconds of time to live per cache
entry, this seems a good compromise.

I haven't throughly reviewed this change, though. I'm quite tired.
Initial testing seems to point this is working, but there might be some
gotchas here and there.  Note to self: review the changes, as they're
large (11 files, ~240 insertions, ~650 deletions) and touch some
sensitive and well-tested parts of the code.