Fix crash from console-commands throwing exception. Fixes BUKKIT-2479

When 1.3.1 was released, a try-catch block was removed from the tick
loop that called the method in NMS to handle commands. This restores a
try-catch to prevent the console from crashing the server.
Add information about async tasks to CrashReports. Addresses BUKKIT-2491

Async tasks are notorious for causing CMEs and corrupted data when
accessing the API. This change makes a linked list to track recent tasks
that may no longer be running. It is accessed via the toString method on
the scheduler. This behavior is not guaranteed, but it is accessible as
such currently.

Although toString is located in the scheduler, its contract does not
guarantee an accurate or up to date call when accessed from a second
thread.
Change local jline checks to not use String literals. Fixes BUKKIT-2455.

Refactoring dependencies 'changes' the string literal in the code. This
commit changes the literal to instead use a char[] to initialize a new
String. On a bytecode level, there will not exist a String literal for these
two values; the shade plugin will no longer refactor them.

Refactoring jline also changes the other String literals we use for
notifying jline of the current state. To insure that our local code reflects
the inner logic in jline, the key value was changed to the static final
variable located in TerminalFactory. Likewise, UnsupportedTerminal uses the
explicit class name (as reflection is used later with the value that has
been set).
Bulk pending cleanup.
[Bleeding] Add autosave interval setting in bukkit.yml. Adds BUKKIT-2507

The new setting is located at "ticks-per.autosave". By changing this
value, it affects how often a full save is automatically executed,
measured in ticks.

This value is defaulting to 0 (off) because we believe that the vast
majority of servers already have a third-party solution to automatically
saving the server at set intervals. Having the built in auto-save disabled
by default ensures that we are not saving things twice; doing so leads to
absolutely no benefits, but results in detrimental and noticeable
unnecessary performance decrease.

For servers that do not use an automated external script to perform saves,
this setting can be turned on by setting the value higher than 0, with 900
being the value used in vanilla.
Reverted changes to chunk saving behaviour.
[Bleeding] Avoid spawn checks on empty worlds. Fixes BUKKIT-2508

Change a server wide check for players to be world specific. Worlds
without players will not spawn entities.
Update the client after a FoodLevelChange event is fired. Fixes BUKKIT-2510
What is dead may never die.
[Bleeding] Check visibility API for sounds. Fixes BUKKIT-2210

This implementation of a visibility API check for sounds
was created by adding extra methods carrying the source entity
in WorldManager and ServerConfigurationManagerAbstract and
adding a test for canSee in the SCMA sendPacketNearby method.
This approach involves no logic copying, just method addition.
I opted to cast to WorldManager as:
1) IWorldAccess is not in CraftBukkit at the moment
2) There is no other IWorldAccess implemented in CraftBukkit,
  nor is there likely to be one soon. If that day comes, easy fix.
CraftBukkit comment fixes
Set last accessed variables after grabbing chunk. Fixes BUKKIT-1033

This fix changes the 'state' of the last accessed variables to be more
accurate. Changing the coordinates of the last accessed chunk should
never precede actually setting the last accessed chunk, as loading a
chunk may at some point call back to getChunkAt with a new set of
coordinates before the chunk has actually been loaded. The coordinates
would have been set, but the actual chunk would not. With no check for
accuracy, this causes fringe case issues such as null block states.

Big thanks to @V10lator for finding where the root of the problem was
occurring.
Replace LongObjectHashMap with a more efficient implementation

After further testing it appears that while the original LongHashtable
has issues with object creation churn and is severly slower than even
java.util.HashMap in general case benchmarks it is in fact very efficient
for our use case.

With this in mind I wrote a replacement LongObjectHashMap modeled after
LongHashtable. Unlike the original implementation this one does not use
Entry objects for storage so does not have the same object creation churn.
It also uses a 2D array instead of a 3D one and does not use a cache as
benchmarking shows this is more efficient. The "bucket size" was chosen
based on benchmarking performance of the HashMap with contents that would
be plausible for a 200+ player server. This means it uses a little extra
memory for smaller servers but almost always uses less than the normal
java.util.HashMap.

To make up for the original LongHashtable being a poor choice for generic
datasets I added a mixer to the new implementation based on code from
MurmurHash. While this has no noticable effect positive or negative with
our normal use of chunk coordinates it makes the HashMap perform just as
well with nearly any kind of dataset.

After these changes ChunkProviderServer.isChunkLoaded() goes from using
20% CPU time while sampling to not even showing up after 45 minutes of
sampling due to the CPU usage being too low to be noticed.