RIP is currently the only thing that can change the number of lines
in the terminal while connected.  This can actually result in there
being more lines on the screen than the last set video mode supports.

There's a "feature" in SyncTERM text modes (curses, ANSI, and Win32
Console) where if the screen mode is "current", it uses the number
of lines in the terminal, but if it's anything else, it forces the
number of lines to the lines in the mode.

This works great until RIP increases the number of lines beyond the
number in the mode... when this happened, RIP would draw the status
bar at the incorrect location on the screen.

This change no longer sets the max rows in the terminal if the
backend can set individual pixels (required for RIP).  Further, to
avoid a delay before redrawing the status bar after RIP changes the
number of rows, the reinit_screen() function now sets a global to
indicate it was called, and the status bar will always redraw when
it's enabled and the flag is true.

This *may* be related to bug 140, but may not be.

Weird stuff happened when dragging a GDI window between monitors
with different zoom (DPI) settings.  The following changes were
all done to clean up this stuff:

Window position is signed
Do some type casting for warnings
Fix return times of GetDpiFor*() pointers
Fix fallback to GetDpiForSystem() (could never be used)
Handle WM_DPICHANGED correctly
Move some copy/pasted code into a function
Fix return value for WM_GETDPISCALEDSIZE
Fix return value for WM_USER_SETCURSOR

Thanks DigitalMan!

Setting this to TRUE reverses the type of cursor used to indicate insert
versus overwrite mode (solid/block cursor veruss underline/normal cursor).
Deuce probably wants to set this to TRUE for SyncTERM.

Add a link to the new generated HTML document, and mention the .adoc
file so people can find it in the future.

Per comment on reddit by dialsoft, the lack of an insert key on
laptops can make manipulating the phonebook more difficult.  Since
all the other UIFC functions have an insert alternate, they don't
need any changes now that there's a manual, but for editing a
string, the insert key is the only way to toggle overstrike.

Since the insert mode toggle persists, simply starting in overstrike
mode should be fine.

Maybe some weird control key of function key can be used (though
I guess laptops don't have function keys either anymore).

I guess that could be mostly good enoughish.

I need to document when I should do this better.

I'll want to generate a version-specific one on release, and want
to ensure it's consistent.

... when PETSCII terminal in use.

For those sysops using editors that don't automatically or easily add this
character to their SEQ art files when needed.

Apparently, /Library/Frameworks isn't searched by default anymore?

Because the appropriate header wasn't included, there was no
prototype.  Not having a prototype is an error in C99, which caused
the test to indicate that there was no va_copy() on darwin.

This in turn caused jsprf.cpp to try to copy a va_list using
assignment.

This is invalid, so the compiler would normally return an error.

Somwhere in here, that error became a clang crash (not trivially
reproducable).

At the end of the day, ancient broken tests in config caused the
darwin Spidermonkey builds to fail.  The new patch fixes up the
configure tests, and darwin Synchronet builds are re-enabled.

Thanks Ree!

Give simple test code a return type (default int isn't valid in C99)
and make some fallback tools executable.

Whoops.

This should normalize everything, with the possible exception of
"zoom" (the thing other OSs call maximized).  Ideally, we wouldn't
allow window size changes when "zoomed" if we could detect the state,
but it doesn't look like we can.

Fixes sourceforge issue 126 (finally!)

Apparently, macOS "maximized" is the same as "fullscreen" in SDL.

Hopefully this is the only lib like this (maybe the resources?)

strListReadFile() can return NULL upon error

Fix CID 509721

Fix for CID 509720