Switch to new Map and Set implementations.

LongObjectHashMap was introduced to improve performance in situations
where we are dealing with chunks. It started out as 3D array with the
first two dimensions based on the chunk coordinates and the last handling
collisions (chaining). This was replaced with an implementation that was
a general array hash table which tended to perform somewhat better.
However, in the current server lookups in this map are still the number one
use of CPU resources so any performance gains are welcome. With this in
mind we now replace this map again with a new implementation.

The new LongObjectHashMap uses an open addressing scheme and uses a
technique called robin hood hashing to deal with collisions. With robin
hood hashing when the desired slot is occupied as we look for an empty one
we also check the entries we find to see if they are in a "better" position
than we would be in that slot. If they are, we take their spot and continue
the search for an empty position using the old entry. This ensures a low and
fairly consistent probe distance for entries which makes lookups much more
performant. Our implementation also uses the backshift strategy on deletion
to keep entries as close to their ideal position as possible. Along with
this we also have a new implementation of LongHashSet which is now a simple
wrapper around LOHM. This uses more memory than a custom implementation but
does not cause any noticable performance loss and simplifies the code.

Performance measurements in a standalone benchmark setting show the new map
is up to twice as fast at containsKey operations and the new set is up to
three times as fast. Measurements in game show containsKey/contains calls
take 40% less time than the previous implementations. Even with a variety
of non-chunk datasets this new implementation benchmarks faster than the
standard Java HashMap, the previous implementation did worse than the
standard for most datasets outside of chunk data.

Included in this commit are improvements to LongHash that make the toLong
method about four times faster. It no longer avoids generating a 0 value
but the new implementations no longer use a 0 key as a special identifier
so this is not a problem. Thanks to @cybertiger for this new LongHash as
well as for feedback, benchmarks, and alternative implementation ideas.