Basically, If we get a FocusOut, call XUnsetICFocus(), and if we
get a FocusIn, call XSetICFocus().  Since we're doing this, don't
call XSetICFocus() unconditionally at start, wait for the server
to send us the initial FocusIn instead.

The only bit I'm not sure of is if I got the times to ignor
messages right... see here:
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html
If you want to check my work.

May fix the focus follows mouse issue reported by Cyan.

From MSDN:
A positive value indicates that the wheel was rotated forward
away from the user; a negative value indicates that the wheel
was rotated backward, toward the user.

Fixes bug 143.

However, this re-opens the confusion around request 75...
nigel and DigitalMan should take a look at this more closely
in rc2 (or an updated nightly).

This describes in more detail how the window size is saved and
restored when starting/exiting SyncTERM.

(e.g. to, from, subject) ... when transmitting to other hosts (e.g. POP3
clients or other SMTP hosts).

For messages that contain CP437 or UTF-8 chars in these fields and were *not*
imported into the BBS via SMTP or POP3, these header fields would be
transmitted to other hosts with the raw CP437 or UTF-8 chars, thus violating
POP3 and SMTP protocols and likely resulting in garbage displayed in message
readers.

The fix is to encode (using MIME "encoded words", per RFC 2407) where
necessary.

Since moderm mail clients (e.g. Thunderbird) don't see to support CP437
charset in MIME encoded header fields, always translate to UTF-8 first.

We probably should be translating message body text to UTF-8 as well, for
maximum compatibilty with modern mail readers, but this commit doesn't address
body text issues with CP437-encoded content. That'll come later.

We can't update a fat static library using ar on macOS. :(

This likely is the cause of bug 140.

The first one, the LCF flag is copied out of the cterm struct
after cterm_end() is called (which frees the struct).  Copy moved
to before cterm_end().

The second one is trickier... it's executing the commands in a mouse
button, and one of the commands is to delete all the mouse button
commands.  This ends up free()ing the string that's currently being
parsed while it's being parsed.  We now use a strdup() of the string
which we free at the end of the function.

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.