Fix for issue #800

Other Ctrl-A codes (e.g. ^A\) might be valid, but they're not attribute
control codes, so their existence would cause this function to return true.

There are still places where it could be logged in <> (if username is not yet
known).

Add JS console.ansi_getdims()

Use sbbs_t::getdimensions() or JS console.getdimensions() to move user
cols/rows values to run-time console values (querying ANSI terminal if
appropriate/supported).

JS console.pushxy(), popxy(), and gotoxy() all return Boolean now.

sbbs_t::getdimensions() and its JS wrapper is now the proper way to propagate
user's cols/rows settings to the run-time console values. This was done
(post-login) only via use of the TERMROWS and TERMCOLS @-codes in
user_settings.js. Weird.

receive_thread() needs to use the control session correctly for
TLS connections.

Ideally, a sysop would never need to disable FTPS support, but as a trouble
shooting measure, it can be helpful.

to node.log via sbbs_t::log()

Some doors/door kits actually require all 52 lines, but since they
(may) have problems with the values we populate on those additional
21 lines, just write them as blank when a program is configured for
the GAP (original) 31 line DOOR.SYS drop file. I doubt (and hope)
that no programs will care if their are more lines than they expect.

So apparently 23 years ago (almost 24), I made a typo in commit
7731d16d that broke the batch transfer menu for RIP users.

Also elminated silly/unnecessary loop-control variable ('done').

I'm working on a port to JS and noticed these oddities (so far).

Removed UTIDOOR.TXT file format: nobody uses this drop file format and we
removed the UTI driver long ago, so this was just an artifact.

If you previously had an external program (door) configured in SCFG to use
the "GAP DOOR.SYS" file format, SBBS will create the same (52 line) format
as before (no change).

But for doors that have compatibilty issues with the 52-line DOOR.SYS file
created by Synchronet (e.g. Thunder cat V3.30), a sysop can now choose "GAP
(original)" for the drop file type and Synchronet will create a 31-line
DOOR.SYS file instead.

Not sure how I missed this one, but this file was needed to complete the
'bbs' object changes mentioned in that commit message.

In response to Reddit inquiry in /r/bbs by wts42:
"is there a possibility in sbbs to restrict access to services like IMAP by
level or flag?"

... now there is.

This only works for services that use the JS login() method to authenticate
the user.

If the services server's LoginRequirements are set in the sbbs.ini file, then
*both* sets of requirements must be met to successfully login to a service.

For exposing the list path/file for a user's batch up/download lists

I obvserved an issue with Amessyroom's bbs where his custom (JS) shell is
setting bbs.menu_dir but when switching to another stock shell, his menu
files were still being displayed (with mismatching command keys as a result).

bbs.menu_dir (and implicitly, the set_menu_dir Baja function) apparently have
not been used in this way (much) before.

For scripts that set the global menu_dir (e.g. via JS bbs.menu_dir), let's
not require that all the files moved from text to text/menu (for example).

Problem reported by Amessyroom when using his custom shell and bullseye.js.

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.

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.

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.

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

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

strListReadFile() can return NULL upon error

Fix CID 509721

Fix for CID 509720

Prevents crashes on modern FreeBSD systems that default to implicit
PROT_MAX in the JS code.
(It's possible that +wxneeded will be needed too.. still experimenting)