We need to track different things in the server and client, so
separate things to two independent structures to keep things more
clear.

We use polymorphic exception objects, so catching by value invokes
the copy constructor and stuff that we don't really want.

They just end up burning CPU fighting each other without much
improvement to the decoding time beyond four threads.

We can start creating more decoding threads now that we handle
rect ordering properly. No point in creating more threads than
there are CPUs though.

Some encodings only cause dependencies between rects some of the
time. Make sure we can allow parallel decoding of those rect that
aren't dependent on each other.

Some encodings must be handled in the order they are received.
Make sure we respect this in the decode manager.

This implements the basic infrastructure for multi-threaded
decoding of rects. However there is just one thread reading data
and one thread decoding it. More logic is needed to safely decode
multiple rects at the same time.

We need to split these steps up in preparation for multi-core
support. Reading needs to be done in a serial manner, whilst
decoding can be done in parallel.

This also involved a rather large cleanup of the Tight decoder.

Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.