Client Overhaul, Client Spawning

Got the client spawning (out of the loading screen) which means that I
can properly develop and test chat-related features now.

This only works with the test front-end.  The code to get the client to
spawn is a massive hack, but is essential for development at this stage.

Overhauled the send functionality of the Client class entirely.

In order to avoid race conditions between sending packets, setting some
condition, and then handling the next packet (what if the next packet
arrives before you finish setting that condition?) the Send functions in
the Client class now support atomic operations.

You can atomically send a packet, enable encryption, change the client's
state, perform an arbitrary task (with a callback), all of the
preceding, or none of the preceding.

This was absolutely needed for authentication support.  The server needs
to send a 0xFC packet (with an empty payload) unencrypted to the client
at the end of the encryption handshake.  After this the client will send
a 0xCD packet encrypted.

This means that you cannot enable encryption and then send, as the
client is expecting cleartext.  But if you send and then enable
encryption you run the risk of being lengthily pre-empted, or the client
being extremely fast, and the receive handler (over which you have no
control) attempting to interpret the encrypted 0xCD as plaintext.

This functionality existed before, but it was not scalable or flexible.
It was shamefully purpose-built to support the specific way I was using
it in the authentication module, which belies the point of modularity
entirely.

The new API -- on the other hand -- is comprehensive.

Accordingly I added an "OnLogin" event to the server which fires
atomically with 0x01 being sent to the client (to complete the
login/encryption handshake).  However this exposed a new problem --
deadlocks.

Upon receiving the callback for 0x01 I had a handler setup to send 0x06
to the client.  I wanted this to be atomic, but the handler was caling
the Client.Send method, which acquires a lock, which the parent function
was already holding.

Therefore I revamped the whole send/receive/communications lock system
to support recursive locking.  Acquiring the write lock in any of the
functions that support callbacks stores the thread's thread ID, and then
for any nested calls to Client functions that would normally lock, the
lock/unlock is simply bypassed.

Shoehorned 0x01 functionality into the authentication module, as that's
currently the most logical place for it.  0x01 is an interesting packet
because it's part of the login/encryption handshake, but actually has
very-little-to-nothing to do with logging in, authenticating, or
encrypting.  It deals almost entirely with properties of the world and
the server's settings.

This functionality may -- therefore -- be later moved into another, more
appropriate module.

I also added cleanup code in server.cpp for the two new events I added
in the last few commits so they don't cause grief with module
loading/unloading.