Force mouse support in graphics mode even if user disabled
it for the BBS.  It would be nice if mouse support in the menus
was a separate option than "terminal doesn't support mouse",
and we know the terminal supports the mouse when we detect
graphics mode.

Move top/margin/width calculations into separate functions.
For level 1, center the playboard.

Fix an apparent off-by-one drawing the title bar.

Hidden behind the graphics option for now since there's still
issues... the board is offset in the window, the level 1 board is
framed wrong (since the graphics are always 2 cols), and it doesn't
check the graphical resolution, so if you're in a weird mode, it
can break.

Also, the graphics are uninspired at best... just hacked them up
in Gimp.

Sneaky hiding extra interesting bits at the end like that. :(

NO_X is defined in the ciolib GNUmakefile.  DISABLE_X11 is defined
on Common.gmake.

Useful to check if SyncTERM was built with or without specific
features.

increase player name width in uberblox lobby

Fix return value when handling WM_SETCURSOR.  Returning FALSE
indicating we didn't handle it stopped the cursor from being set
to the size arrow cursors.  Instead, pass it to DefWindowProc().

While we're here, handle WM_SIZING to make it more clear that you
can't change the aspect ratio by dragging.

Add a comment explaining why we do what we do, and verify the aspect
is unchanged as well since we could change only the aspect and need
to set new hints in some cases.

This breaks at least herbstluftwm's focus-follows-mouse, and rustles
Cyan's jimmies.

It's also a terrible idea.

quitting needs to be set to true, not false when quitting. :(

Using snprintf() prevents the last character of the date from
being put into the string.

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).