There's still some dependency weirdness on Linux, and cryptlib
won't automagically rebuild if the patches change, but it at least
works for an initial build, which is the primary use-case.

None of this has been tested on Windows yet.

Except when it doesn't... it's harmless to link with it then though.

The tricky part is really extracting the source and applying the
patches THEN configuring cryptlib.

I can do this with ExternalProject, but I'm not sure exactly how
to hook this up yet.

This also requires patch and perl and a supported md5 thing to be
installed in a place CMake will find them, which sill be
challenging for Windows.  If Windows (or compilers for Windows)
have started shipping with git, I can use git apply instead of
patch, but the rest is still kinda fuzzy.

This does at least fix up the terrible serialized build though,
so once I get this working, it will work well with values other
than -j1.

"upload.*" is an optional menu file, so this should've always used the
P_NOERROR flag, but the bug just fixed (in commit b656e19f) masked this
issue.

This issue was introduced in commit d02fc1a2 (3 years ago), where menu() would
silenty fail (just return false) if no display file matching the supported
menu/display file types/extensions could be found.

Previous to commit d02fc1a2, we would log a NOTICE-level message and display
a "File not found" message to the user (what sbbs_t::printfile() does), but
since d02fc1a2, we no longer even call printfile() when the file doesn't
exist, so no error was logged or message displayed to the user.

Of course, when using the P_NOERROR mode flag, silent failure is expected and
that's still what happens in that case.

They're tricky tricky tricky tricky.

So we can be sure it keeps working.

Allows arbitrary sized windows on Darwin... the OS is still scaling
the window contents though rather than allowing us to dynamically
update them.

Normally, when modifying user fields via JS, the "user modified" node.dab
flag would be set for that user (on all node's that user is logged-into) and
the user record automatically re-read (soon after). But this doesn't work
during newuser registration because the user is not yet "logged-into" a node.

This fixes the issue reported by Nelgin (and observed on amessyroom's BBS)
whereby if a new user resets/changes their external message editor, it would
not take effect for their new user validation email to the sysop (they would
still be using the default new user message editor as configured by the
sysop).

It's possible other new user default changes made (e.g. language) would also
not have taken immediate effect as a result of this bug (now fixed).

Previously, when multiple lists were passed, the "write" parameter
(which can't be changed) was applied to all sockets.  This means
they would always all be poll()ed for read, then checked for the
appropriate flag (read/write/priority)... which effectively meant
that only the first (read) array would work.

Can't seem to get it reliable using the SBBS mouse parsing... doing
it all myself for now until I decide if it's neat enough.  I'll
need to try it from a remote location to see how the latenct impacts
playability.

Remove more of the obsolete stuff.

Too many tools are gungo-ho over UTF-8 these days.

CMake is now fixed, and a NetBSD extra wait for key on exit with
the system curses is also fixed.

PC Speaker can't actually be disabled, so remove it from build options
listing.

Allows top-level wrapper CMakeLists.txt files to work (as long as
their project name is right).

Much easier to fix it this way than to figure out why X11 needs to
init it before bitmap_con does.

All of this code runs in the same thread, races aren't possible.

If the last is freed while the screen is being updated, and the use
after free bug is not detected, corruption could occur resulting in
bad areas of the screen that persists until the window gets an
expose event again, or the impacted pixels are updated again.

Possibly fixes an issue reported by nelgin via IRC.

This fixes bug 141, which is currently the last blocker for rc2.

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.