use the right hashpower for the item_locks table

For some reason I can't understand, I was accessing item_locks via the main
hash table's power level, then modulus'ed to the number of item locks.
hashpower can change as the hash table grows, except it only ever changes
while no item locks are being held (via the item_global_lock synchronization
bits). The item_locks hashpower is static for the duration.

So this isn't a safety issue, but instead just using the hash table wrong
and doing an extra modulus.

As an aside, this does improve benchmarks by a tiny bit.
add test for issue_260

Only for posterity... See notes in the test file for how to use it. Test is
normally skipped. Will cause an assert under old versions of memcached.
disable tail_repair_time by default

We've cleaned up a lot of the refcount leaks lately, and this feature does
have a race for soemthing grabbing active data from the tail.
don't fetch yourself during memory allocation

It was possible to, while replacing an item, find your own item from the tail
and examine it. This reverse some logic and adds a not-completely-covering
check of ignoring an item if it has the same (complete) hash value.

This is the second half of the general fix for the infamous "issue 260" from
google code bugs.
Take endianness into account on alignment check
Reworked C-alignment check to be clear-as-day.

See bug/pull discussions
 - http://code.google.com/p/memcached/issues/detail?id=100
 - https://github.com/memcached/memcached/pull/3
 - http://code.google.com/p/memcached/issues/detail?id=360

Conflicts:
	configure.ac