[Bleeding] Correctly enchant books. Fixes BUKKIT-5302

Books can now recieve more than one enchantment.  As such, breaking out of
the loop after only 1 enchantment is applied is not the correct behavior.

This commit also reworks some of the logic surrounding the application of
enchantments to the item. By checking if the event doesn't add any
enchantments rather than if the original enchantments list is empty, the
application code is only reached if enchantments are applied, rendering
the "applied" boolean no longer necessary. The ItemStack's Item should only
be set once, so it is now set outside of the loop based upon whether or not
"flag" is true (with "flag" being whether or not the ItemStack's Item is a
book).
Implement banning API. Adds BUKKIT-3535

Previously no implementation existed to access various additional
information fields regarding bans. This implementation expands on the
information outlined in the sister Bukkit commit to provide access to
the Minecraft implementation of the ban system.

This implementation of the banning API contains 2 new classes which
provide access to the internal workings of the built-in banning
system within Minecraft.

The CraftBanEntry class simply supports the representation of an internal
Minecraft BanEntry object. The data that may be modified within this new
object must be manually saved to the list contained within the
CraftBanEntry using it's save() method.

The CraftBanList class supports the representation of an internal
Minecraft BanList object through proxy methods. These methods do
validation on the passed objects where needed to ensure safe input to the
backed Minecraft objects.

These changes additionally re-route the existing banning API to the newer,
more detailed, system. Functionality prior to this change still behaves
as documented by the contract defined by the methods changed.
[Bleeding] Implement Mojang command fallback system. Adds BUKKIT-5385
Match old alias behavior when migrating.

Previously the alias system would pass all arguments from the alias
to its command(s) implicitly. The new system requires arguments to be
explicitly passed so server owners can have more control over where and
how they are passed. To ensure this isn't a breaking change during the
migration from bukkit.yml to commands.yml we now add the $1- argument
to the alias commands to match the previous behavior.
Readd BlockPlaceEvent for half slab to full block. Fixes BUKKIT-5390
Add method to forget callbacks in AsynchronousExecutor
Handle removing entity while ticking. Fixes BUKKIT-1331

If a plugin causes an entity to be removed from the world while the
world is ticking entities the ticking loop gets out of sync and fails due
to trying to go beyond the end of the entity array. To ensure this doesn't
happen we store the loop position as a field so we can fix it up in the
entity remove method just like the tick method does when it removes an
entity.
Readd diff missed in the 1.7 update.
Hide message from connection throttle on startup. Fixes BUKKIT-5403
Rename Minecraft command permission nodes to meet fallback spec.
Add PlayerSelector.java for diff visibility.
Ignore player selectors if not a Command Block.
Update/improve configuration documentation.
Check if entity is in list before decrementing. Fixes BUKKIT-5404
Updated version to 1.7.2-R0.3 in pom.xml for Beta.
Updated version to 1.7.2-R0.4-SNAPSHOT for development towards next release.
Remove chunks from queue if we don't need them anymore.
Update CraftBukkit to Minecraft 1.7.5
Increment loop index whether or not command succeeded. Fixes BUKKIT-5455

When VanillaCommandWrapper dispatches a command containing a
PlayerSelector wtih c>-1 (implicitly true for @a), it loops over the
selected players and exectures the command with each player. However, the
loop index is only incremented if the command fails. As a result, a
successful command is repeated on the same player indefinitely, locking up
the server. This commit fixes the issue by incrementing the loop index
regardless of whether the command succeeds, ensuring the command is only
executed once per player identified by the PlayerSelector.
Fix teleport failing right after join. Fixes BUKKIT-5479

Teleporting a player checks to see if the player is disconnected to
try to avoid creating ghost players. The check it uses, however, randomly
fails when the player is in the middle of joining the server. The check
that would work correctly here does not work correctly when the player
actually disconnects. To work around this we add a new flag which is
cleared on the first tick of the new player and assume they are connected
if the flag is set.