Created sbbs_t::batch_upload() and JS bbs.batch_upload()
returns true if one or more blind-uploads were received and all files in
the batch upload queue (if any) were received

The Rainbow Ctrl-A codes (x|X) are not valid for message (there's no universal
ANSI equivalent) - so treat as "invalid Ctrl-A codes" for most (message) uses.
e.g. they're stripped when entered into text with the internal message editor.

sbbs_t::chkpass() and JS bbs.good_password() now default to *not* requiring
the password to be substantially different from the user's current password.
This fixes weird issues where a user that just wanted to add more characters
to their current password woudl not be allowed by cause the new password was
"too obvious"
JS bbs.good_password() now accepts an optional second argumnet: forced_unique
which defaults to false.
sbbs_t::chkpass() (JS bbs.good_password()) would always return false if the
provided password was the same as the user's current password, regardless of
the 'unique' parameter value. Now, only reject unchanged password when unique
is true.

sbbs_t::upload() and JS bbs.upload_file() now accept an optional second
argument: 'filename' which when specified, the function won't prmopt for the
user-supplied filename.

New JS property: file_area.max_filename_length

file_area.min_diskspace, settings, and web_vpath_prefix are now read-only.
These properties should not have been writable.

This text/terminology was pretty out of date.

That was a badly named function.

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.