Add "min_ms_between_frames" cvar for framerate control.

This cvar sets the minimum time in milliseconds between frames, and
therefore puts an upper limit on the frame rate.  Note that input and
other processing is also tied to the frame rate, i.e. this does not
only affect video output.  It defaults to 1, which is essentially
unlimited.
Fix slow Fake Hitler fire projectiles when framerate is not low.

http://wolfenstein.wikia.com/wiki/NewWolf?oldid=19338 notes that "On
higher resolutions, the projectiles fired by Fake Hitlers travel much
more slowly than they are intended to."  As noted in
http://wolf3d.darkbb.com/t2089-bringing-newwolf-back-to-life#24350,
this is incorrect - the issue occurs with higher frame rates, not
higher resolutions, and occurred in the original game too.
http://maniacsvault.net/ecwolf/notes.php points out that the problem
is that, for these particular projectiles, the movement function is
called once per frame instead of once per tic.  This fix calls the
function from the correct slot.
Don't keep moving forward after holding down 'forward' for a while and using mouse.

If you walk or run forward for a while and use the mouse to turn while
doing this, after you release the button for 'forward', you may keep
moving forward for a while.  The amount of time that you keep moving
forward is increased based on the amount of time that 'forward' was
held, the amount of mouse movement used, and the lower the framerate
gets.  This issue was originally reported in
http://web.archive.org/web/20030608162220/http://hosting.gotdotnet.ru/DarkOne/phorum/showthread.asp?id=106

During debugging, it was found that the key handling code was stopping
the forward movement as soon as the WM_KEYUP event was received, but
reception of this event was delayed until some time after the key was
actually released.

The problem was that only a single Windows message was processed each
frame, so that as the framerate got lower and the amount of user input
increased, the backlog of unprocessed messages became quite large,
causing the WM_KEYUP event to not be processed until quite some time
after the key was released and the message was sent to the process.

This fix causes the message handling code to process all available
messages each time it checks for messages (once per frame).
Add Debug_Printf() function to print to Windows debugger

This function is useful for outputting debugging information without
cluttering the console output.  Its output appears in Microsoft Visual
Studio's "Output", Sysinternals/Microsoft's DebugView application,
etc.  No users of the function will be committed initially.
Minor code tidying: CL_BaseMove().

Remove a variable that was set but never used, and add some comments.
Secret push walls should stop moving after at most 2 blocks, not 3.

As reported at http://forums.3drealms.com/vb/showthread.php?t=35359,
in episode 6 map 2, the when the secret push wall in the south-west
corner of the map moves 3 blocks, it prevents access to the rest of
the secret.  That thread references a bug in the original Wolfenstein
3D where push walls would sometimes move up to 3 blocks (taking into
consideration collisions), sometimes 2, being more likely to move up
to 3 blocks with higher frame rates, but that is not relevant in this
case.  The code in NewWolf for push walls is modified or rewritten,
and does not appear to suffer from this non-determinism.  However, it
does explicitly limit push walls to moving at most 3 blocks, which is
not consistent with the original Wolfenstein 3D code that attempted to
stop them after 2 blocks.

This fix changes the limit to 2 blocks for consistency with
Wolfenstein 3D and Wolf4SDL 1.7.