Don't check unload queue before ticking things anymore.

In commits 71a238ee and c8591397 we added checks while ticking to ensure
we never ticked anything in a chunk meant to be unloaded. We did this to
prevent these chunks being removed from the unload queue and leaked.
However, this causes a ridiculously large number of lookups on the queue
for a somewhat rare occurance. We also now have the chunk GC which will
take care of these leaked chunks when they do happen. With this in mind
we now remove these checks which removes almost all uses of the
LongHashSet backing the unload queue.
Avoid checking for loaded chunks for lighting and entity ticking.

When a chunk is loaded the server tries to ensure it has its initial light
calculations done before sending it to the player. When ticking entities
the server tries to ensure the entity does not walk into an unloaded chunk.
To accomplish these the server checks a one chunk radius around the chunk
to be lit or a two chunk radius around the chunk the entity is in. These
lookups happen every tick even though their result is unlikely to change
that often. To reduce the cost of these checks we replace them with a
system to keep track of what neighbor chunks a chunk has loaded and update
it when chunks load or unload which is a much less frequent action. On a
server with ten players this change removes about 100,000 calls a tick to
LongObjectHashMap's containsKey method.
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.
Avoid unnecessary double chunk map lookups.

Several places in vanilla check if a chunk is loaded and if so get the
chunk. This is two effectively duplicate requests for one chunk. To avoid
this we add a new getChunkIfLoaded method and make use of it in high
traffic methods. There are other places that do these pairs of calls as well
but profiling did not show them getting called enough to be worth the diff.