Mod support

Changed a lot (most?  all?) of the places where I'd defined functions to
only take rvalue references to take by value.  I don't even know what I
was thinking when I made the functions only take rvalues.  You can
std::move() into a parameter that takes by value and it's the same thing
without the added cognitive overhead of typing &&.

The only place this still persists is in the Connection::Disconnect
function, because it actually does do different kinds of handling
depending on what kind of reference it's passed, because it's written in
such a way that it will always complete even if copying the string into
itself fails (it can't fail with rvalues, can with const lvalues).

Added mod support into the server.  Mod support is implemented through a
component (which mods can then shamelessly steal to load mods
themselves, I love modular design) called ModuleLoader.  The
ModuleLoader targets a certain directory, and when instructed to load
mods it enumerates that directory and grabs every DLL/SO (depending on
the platform it's compiled for) and dynamically loads it.  It then
attempts to find a function with the signature Module * Load () (which
obviously have to have C linkage, and therefore implicitly cannot throw)
and calls it.

If this function return nullptr, the module is considered to have
encountered an error and is immediately unloaded.  If the function
returns a pointer this is the server's handle to the module.

When the ModuleLoader is instructed to install mods, it calls the
Module::Install() function which tells the mods that they may hook into
the server.

When the ModuleLoader is instructed to Unload it calls the void Unload
() function in each loaded module (again, C linkage).  This function is
expected to be resilient (i.e. if it's called once, twice, et cetera
it's expected to behave properly, so it must track the lifetime of its
own Module *).

When the ModuleLoader is destructed it will drop the dynamically loaded
modules from the server.

There's an example of an implemented mod in ping/main.cpp, which adds
Server List Ping functionality to the server (i.e. it allows the server
to populate the data in the Minecraft client's server listing).

There's currently some kind of bug I'm working on hunting down in
mysql_data_provider.cpp which causes it to panic (I know what causes
this bug -- the server goes away so all prepared statements are
invalidated) and randomly SIGSEGV (no idea what's causing this...working
on it...I think it may be related to the panic bug, but not 100% sure, I
can't seem to isolate it in the debugger).

Added the necessary methods to the Server class for mods to hook into
what functionality is currently implemented (as seen used in the Server
List Ping module).

Since I'm going to start writing more and more modules, added global
new/delete overloads to avoid cross-library memory problems.  These hook
into the RLeahyLib::Memory functions so the allocation is also
consistent with RLeahyLib and may be used with SmartPointer, et cetera.
Actually thinking of merging this into RLeahyLib, but I'm not 100% sold
on this idea yet.

Fixed an undefined behaviour bug in PacketRouter.

Update the server shutdown to support destroy resources that may have
been added/replaced by mods before actually unloading those libraries by
calling the ModuleLoader destructor (not doing this causes SIGSEGVs).