Console logging -> thread

I'm not sure I like this but I'm not sure I don't either.

This has the following affects (not sure if all are good):

 * Debug builds now run at usable speeds (most of the time, at least on an i7.)
 * Scrolling the console no longer pauses gameplay (split on good/bad.)
 * OutputDebugString is now defined off even in debug (it's just so slow.)  Personally, I'd rather use OutputDebugString for spot-debugging rather than logging.
 * Log can be behind sometimes, so after hitting pause it'll take some time to catch up.
 * It's no longer easy to see what's immediately going on while the game is running.

With this, debug spends most of its time in CityHash (might be nice to just make that always optimized...) and sprintf() still for logging.  But it's a lot less.

Before, in debug, it was spending 51% time in WriteFile/SetConsoleTextAttribute, and 37% time in OutputDebugStringA.  And 12% (the rest) in the CPU/GPU/sprintf part of logging/etc.  Now that 12% becomes ~95% (after overhead for copying data to logging.)  It also improves perf in release (except on single core machines where I bet it hurts), although I didn't measure too  that carefully as it wasn't my goal.  Theoretically it has no real effect on non-Windows.

It's still spending 23% time in logging in general, but CityHash (~35%) is more.  Also, updateSyscallStats is probably too expensive (~12% time in debug.)

So, some downsides and some upsides.  What do you think?

Also, not sure if I was too careful/not careful enough with the threading.  Don't have a lot of experience there as I usually just communicate using sockets/etc.  Maybe the code could be cleaner...

-[Unknown]