Improve throughput a little

[davidrg]

This PR builds on previous work done late last year to improve throughput a little by:

• Not using semaphores to track vscreen dirtyness in GUI builds - the GUI renderer never waits on the semaphore so there is no benefit to its overhead. The old console mode renderer does wait on them, so it still uses them.
• Use CRITICAL_SECTION instead of mutexes for the TCP/IP socket, Local Echo Buffer and SSH ring buffer improving throughput for SSH connections a little and non-SSH connections quite drastically.
• Replace the NetCmd input thread (also used for PTY connections) with a new implementation that works the same way as the SSH subsystem and reuses its ringbuffer implementation.

This cuts the time it takes to handle a 10MB text file being dumped to the terminal from 5.94 to 1.7 seconds for SSH, and 15.59 to 1.9 seconds for telnet. PTY/pipe throughput is now about the same as SSH.

For comparison:

• K95 3.0 beta 7: 56.48 seconds for SSH, 15.59 seconds for telnet, 2 minutes 50 seconds for a pty/pipe
• TeraTerm: 26.29 seconds
• Putty: 1.51 seconds
• Windows Terminal: 1.39 seconds

~1.7 seconds is probably fine - no one can read that fast, so its really about making sure accidentally catting a huge log file doesn't cause problems (which it absolutely does in the current K95 release).

I don't see any other obvious low hanging fruit at this point. Any further gains in throughput will probably come down to minor tweaks that individually only make a very small difference. Based on some further experimentation with the profiler, probably things like:

• Reducing unnecessary function calls. Eg
  • Function that just wraps another with slight parameter tweaks - just call the wrapped function directly
  • Function that checks a boolean and does nothing it its not set - check the boolean before calling rather than wasting time on a function call
• Improve the way VscrnScrollPage erases lines by keeping a cached blank line that can just memcpy'd, rather than iterating through all the cells erasing them every time.

TODO:

• Investigate some of the above things and commit anything that does make a measurable improvement
• Look into dropping the compiled-in default render interval from 100ms to 20ms so that anyone not using the default config file shipped with recent K95 releases (which sets it to 20ms) doesn't have to suffer the abysmal latency of K95 2.x.