Add setwinsize and setwinpos
Move blit from rect into gdi_thread
Add beep support
Add (non-functional) settitle support
Support ciolib scaling in addition to GDI scaling
Add window-size snapping
Support -iG in SyncTERM

GDI is still the second-least preferred mode, so auto mode will only
use it if the windows console somehow fails.  But at least people
can play with it.

Fixes issue on Linux where the window size is constantly updated,
and window rabidly steals focus.

This lock has devolved into a wrapper lock for vstatlock.

Use pthread_once() for init_mouse() instead of a global
Fix some lock issues in cb_drawrect()

When fast scrolling, memmove() takes most of the CPU by far... it
is likely actually worth having each line be a buffer of its own
and just moving the pointers around.  To help with this optimization
in the future, move the screen memmove() bit into a separate function.

Fix a couple warnings while we're here.

This should almost completely remove vstatlock contention in SyncTERM,
which should bring SDL output performance close to X11 performance.

This makes cvstat work as intended, so we no longer need to lock
vstatlock when accessing it since it's only accessed from the
video event thread.

There's still an irritating dependency on vstat for ALT-Enter handling.

When originally created, it was intended to be accessed only by a
single thread, and therefore not need mutex protection, allowing
less code to run with vstatlock held.  Unfortunately, this is not
how it turned out, so cvstat should either be removed, or it should
actually be cleaned up to work as intended.

for an extended time.  Should fix SDL mode slowness.

Only call RenderPresent() if we called RenderCopy().  Should fix
SDL mode flickering.

1) Unreachable return without a lock in sdl_useR_func_ret() (harmless)
2) LOR in handling SDL_USEREVENT
   - vstatlock was obtained inside of win_mutex which should never
     be done... this could (and likely does) result in a deadlock
     when using SDL mode.

sdl_setwinsize() and eliminate another race.

Pass window size in SDL_USEREVENT_SETVIDMODE
- Fixes race condition where SDL_WINDOWEVENT_RESIZED or
  SDL_WINDOWEVENT_SIZE_CHANGED arraves while
  SDL_USEREVENT_SETVIDMODE is in the queue

Set new scaling based on old scaling multiplier
- Will resize window on mode changes, but tries to keep integer
  multiplier similar.  May break fullscreen modes, dunno.

Have aspect_fix() return higher rather than lower
- This may make it the same as aspect_correct(), but I'm too lazy
  to figure that out.

Add additional stderr debugging.
Don't try to correct the aspect ratio of the window.

While we're doing that, actually use it in SyncTERM so the offline
scrollback retains fonts.

Also, fix an issue where the current mode would be updated with
the custom parameters when you changed them.

Finally, remove some unused variables.

Now that ALT-Up/Down no longer have an effect on window size, they
can go back to their previous bindings of changing the emulated
output speed.

At the same time, remove AltGr support from keysym parsing since it
should be properly handled by the text input stuff now.

People are used to thinking about the aspect ratio of displays and
used to not thinking at all about that of pixels.  Most of the modes
are simplt 4:3 modes and the text area is the entire window.  The
only oddball here is the Commodore 64 and 128 40-column modes.
Because they have a border around them that's wider on the sides than
the top/bottom, the display aspect ratio is actually narrower than
a normal NTSC screen (6:5).  It seems the PAL version actually has
square pixels, but nobody has asked for a PAL Commodore mode, and I
think that has a different colour palette too so I'm not doing it.

Just to frustrate DigitalMan a bit, the default custom aspect ratio
is now 4:3 (but can be configured).  At present, modifying the custom
mode while *in* the custom modes "works", which no sane person would
want when adjusting the aspect ratio.

Microsoft wants us to use a manifest for this, but I really don't
feel like digging into however one uses manifest files when not
using the Microsoft build files.

Details here: https://docs.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process

This may solve issue where using Windows "DPI scaling" forces the
window to be scaled.

Also, include math.h

Simplest way is to use the alt-left/right snapping.

This fixes all the window adjustment "stuff", but the new aspect
ratio enforcement means that ALT-UP and ALT-DOWN are useless for
resizing the window unless it's not already snapped... use ALT-LEFT
and ALT-RIGHT to decrease/increase the window size.

Also, the 8x16 font at 80x25 is *not* a square pixel aspect ratio.
As a result, it now stays "proper", which is likely not what you
want.

This was discovered when I was trying to make DigitalMan happy
because he wanted the apsect ratio retained on scaling.

Sorry for the impending imminent scaling hassle DigitalMan!

This is pretty insane since SDL2 completely ignores the keysym value
of the X11 keyboard event, so here's what we do...

1) When there's a keypress that includes right-alt, store the sym/mod
2) When we get text input, if it's the same as we would get if ALT
   wasn't pressed for the last keydown, parse through the mapping
   (ie: handle ALT keys)
3) If it's different, use that (gets AltGr modified value)

I get that AltGr is hard in a cross-platform way, but just pretending
it doesn't exist at all for key input is a very weird choice.

With maximized windows, unexpected behaviour occured when the program
resized itself, then the window manager minimized/restored the window
Should address SF bugs #18 and #13

Make an exception for all keypad stuff.

There are a number of conio changes in here too... too many to list.  Check
the diffs if you actually want to know what changed.

May fix https://sf.net/p/syncterm/tickets/19/

Please try to log in to SourceForge when creating issues or I won't be able
to contact you with follow-up questions or get confirmation when an issue
is resolved.

a new texture with the same address as a destroyed texture causes crashes.
Just allocate the new texture before freeing the old one to prevent that
from occuring.

These allow setting the initial window size for modes that don't force
integer scaling (ie: SDL).

While we're here, clear a renderer before free()ing the texture to prevent
crashing on some nVidia cards.

Addresses https://sf.net/p/syncterm/feature-requests/17/