Bumping to 3.0.2-SNAPSHOT
Adding a new ChunkCoordIntPair wrapper.
Starting to add unit tests for PacketType.
Added support for cloing ServerPing packets.
Fix ConcurrentPlayerMap to use SafeCacheBuilder
Merge pull request #26 from YukonAppleGeek/master

Fix ConcurrentPlayerMap to use SafeCacheBuilder
Update Readme.md to include Java and YAML syntax highlighting
Merge pull request #27 from ttaylorr/master

Update Readme.md to include Java and YAML syntax highlighting
Add support for the latest build of Spigot.

See commit 8b2b731ea5deda5607058849f2ca9ec2e3bf003f in SpigotMC/
Spigot-Server.
Correctly clean up the old injection handler.
Significantly reduce the possibility of a race condition.

The vanilla server bootstrap (ServerConnectionChannel) is executed 
asynchronously when a new channel object has been registered in an event
loop, much before it is ready to accept a new client connection. It is 
here the whole channel handler pipeline is set up, along with a 
NetworkManager responsible for reading and writing packets. 

The trouble starts when the bootstrap class adds the created 
NetworkManager to a list (f) of managers in  ServerConnection. This list
is regularly inspected by the main thread (in order to process packets 
on the main thread) and includes a clean up procedure 
(ServerConnection#61) in case it detects a disconnected network manager.

Unfortunately, the network manager IS considered disconnected for a 
moment when its added to the list, so the main thread MAY end up 
getting to the network manager before Netty has connected the channel.
This is still very rare under normal circumstances, but because 
ProtocolLib does a lot of initial processing in the channel handler, the
asynchronous thread gets hold up for a long while the first time a 
player connects to the server, allowing the main thread sufficient time 
to catch up and evict the network manager.

The partial solution here is to synchronize on the network manager list,
stopping the main thread from processing network managers when we are 
preparing our new connection. 

But I suspect the best solution would be to correct the root of the 
problem, and correct the race condition in the server itself. This 
could be done by only adding the network manager when the channel is
active
(see ChannelInboundHandler.channelActive).
Correct a missing noEntryValue in Spigot.

Again.
Don't override the network manager list unnecessarily.
Fix a race condition we created while fixing another race condition.

They're everywhere.
Make it possible to modify the player list in the ping packet.
Set the correct option when calling optionAsync().
Don't synchronize with the main thread when registering async listeners
Ensure ProtocolLib functions in 1.6.4 and below.
Actually fix the ServerPing wrapper.
Update the player instance during PlayerLoginEvent as well.

This ensures that we at least have an OfflinePlayer when certain
packets are intercepted, instead of the TemporaryPlayer created 
by ProtocolLib.