Commit permissions API specification and default implementation by me and @AbrarSyed
Rework OreDictionary's internals to be a bit more speedy to help combat modders using it inapropriatly. Closes #1022 Closes #1131
Changed EntityWolf to EntityTameable in EntityLivingBase.attackEntityFrom, to allow for more custom pets. Closes #1141
Fixed inverted player parameters in PlayerEvent.Clone, Closes #1142 Closes #1140
Fix not being able to change target & attackDamage for EnderTeleportEvent.
World fog color and density can now be controlled through an event
Fixed missed metadata offset, and now cache return values of getOres for speed.
Changed dustLapis to gemLapis to make OM SHUT THE HELL UP.
Warn when chunks are being self-recursively loaded. This can cause serious issues. Modders should watch out.
MinecraftForge/FML@1a99ec7db612f258983c6ac685da906bf7cde0a6 Deprecate getAABBPool so people can stop using it in mods. Failure to do so will result in 1.7.10 upgrade incompatibility. Use getBoundingBox instead.
Pop version for new Recomended build.
Add missing onLivingJump calls
Load chunks asynchronously for players.

When a player triggers a chunk load via walking around or teleporting
there is no need to stop everything and get this chunk on the main thread.
The client is used to having to wait some time for this chunk and the
server doesn't immediately do anything with it except send it to the
player. At the same time chunk loading is the last major source of file IO
that still runs on the main thread.

These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure.  The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.

There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.

The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.

Thanks for ammaraskar for help with the implementation of this feature.

This commit is based off the following :

Bukkit/CraftBukkit@b8fc6ab2c12e9b4c8d7b5370e44f23cc838014b2
Bukkit/CraftBukkit@85f5776df2a9c827565e799f150ae8a197086a98
Bukkit/CraftBukkit@0714971ca2a31bc729bdd78ded8c69ffb2284813
Bukkit/CraftBukkit@7f49722f457dcc31f8cac8e011871ff1b7fd3306
Bukkit/CraftBukkit@53ad0cf1abe9c060ef411a86e9a16352f3e5197e
Don't call ChunkDataEvent.Load async

ChunkDataEvent.Load must be called after TE's are loaded since this is
what mods expect. The event is handled by ChunkIOProvider during
callStage2.