1.6 and Start of World Generation

1.6.1 hit, so made a few updates pursuant to that:

1. Changed the definition of the Ping (0xFE) packet to reflect the
realities of the new Ping packet (which is an old 0xFE followed by a
0xFA).

2. Changed fully over to JSON chat, discovered that it does not work as
advertised, so I switched back and added the requisite hack to make old
style chat work with the new JSON chat.  This is a hold over until
Mojang fixes the way the client renders the new JSON chat.

Fixed a couple of bugs which could cause segmentation faults in certain
situations in the network stack (both Windows and Linux).  The most
serious of these involved invalidation of an iterator while iterating
using that same iterator, which would cause a segmentation fault anytime
the server was shut down with a client connected.

After reading about chunk/column serialization more in depth, switched
over to a per column strategy rather than a per chunk strategy.

When columns are serialized they are not serialized as a collection of
chunks, they're serialized as a monolithic column.  I.e. the block type,
metadata, light, skylight, and add arrays are individually concatenated
so there's one large block type, metadata, light, skylight, and add
array for the column, rather than individual smaller ones for each chunk
in the column.  This means that storing the world on a per chunk basis
would involve massive amounts of copying (since everything would have to
be rearranged) whenever anything more than one chunk is sent over the
network.

Storing the world on a per column basis means that minimal copying is
necessary.  The world is stored -- both in the backing store and memory
-- in the format required for serialization, which means that no
intermediary copy is necessary, the column can be compressed directly
from memory with no additional processing required.

The old Chunk class still remains, but is slated for removal at sometime
in the future.

Updated DataProvider and MySQLDataProvider to be able to handle
loading/saving columns instead of chunks.  Chunk-handling functionality
will be removed completely (it remains commented out) when the Chunk
class is removed.

Started developing a world/world generation framework.  This went
through several iterations until I settled on a custom lock object as a
concurrency mechanism.  The WorldLock class allows for lock acquisition
on:

1. The entire world, which excludes any other thread from accessing any
block or column while it is held.

2. A particular column or columns, which excludes any other thread from
accessing those columns or any blocks within them while it is held.

3. A particular block or blocks, which excludes any other thread from
accessing those blocks while it is held.

The most significant aspect of this lock is that it is fair.  Locks are
satisfied as often as possible but in order they were requested.  This
means that if the following lock requests are submitted in this order:

1. Blocks {1,0,0,0} and {1,1,0,0}

2. Column {0,0,0}

3. Block {2,1,0,0}

4. Block {16,0,0,0}

The locks shall be acquired as follows:

1. Shall acquire the lock as it was first in line.

2. May not acquire the lock as both blocks locked by #1 are within the
requested column.

3. May not acquire the lock (even though it does not contend with any
lock currently held) as it acquiring the lock would be liable to starve
#2.

4. Shall acquire the lock as it does not contend with anything else.

This is very important due to the multiple tiers of locks available.  If
the lock was not fair, and simply satisfied locks as greedily as
possible, then a world-level lock could be blocked indefinitely by an
endless, overlapping stream of block-level locks.

In keeping with the event-driven/asynchronous design of the server, the
WorldLock class also allows for asynchronous lock acquisition.  A thread
may submit a callback to the lock, along with the parameters for the
type of lock it wishes to acquire, and continue at once.  At the
earliest point in the future where the requested lock may be satisfied
the lock shall be acquired, the callback invoked, and then the lock
released as soon as the callback returns.

In addition to the advantage of not incurring any blocking, this
asychronous method of lock acquisition is also totally and seamlessly
exception safe without any cognitive overhead on the part of the
programmer.  The lock is guaranteed to be released when the callback
returns, whether it returns normally or by throwing.