text description of last socket error that occurred

Define a thread-safe/re-entrant version of strerror(): safe_strerror() which is just thin wrapper around strerror_s on Windows and strerror_r elsewhere.

Some other timed event related configuration text/help fixes/beautification too.

The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner.
Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged.
The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs).

I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because:
- that's where the validation user number is already set
- I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors

The problem: the sysop (me) is not notified of critical errors (e.g. synchro.net zone file problems) in a timely manner.
Part of the solution: notify a configured user (e.g. user #1) via short-message/telegram and email/netmail logged-errors when messages of a configured severity (e.g. "Critical") are logged.
The second part of the solution (coming next) will be allowing timed events to log a message of a configurable severity logged when the event fails (returns a non-zero error level to sbbs).

I'm saving the error-notification-user-number and log-severity as part of the node.cnf file because:
- that's where the validation user number is already set
- I can conceive of a large system were certain node ranges (different instances of sbbs) might want different operators to be notified of logged-errors

This also means I eliminated all the legacy com port/modem stuff from the end of the node.cnf file. None of that is used in sbbs v3.

Also included in this commit are improvements around logging:
- reduce the severity of UDP recvfrom failures in services
- a more detailed log message when the mail server successfully delivers an email (via SMTP) - easier to answer the question: was that email you/they sent delivered successfully?

Use Microsoft magic to "ignore regular line breaks in the message definition text." of socket error strings on Windows:
strips the embedded line-feeds from the socket error description.

(and their terminal supports) mouse reporting.

Allow set_mouse() to disable mouse-reporting in the terminal (if it was previously enabled), even when mouse support has been turned off by the user.

for the (newly-added) TerminalMouse string.
Also added MouseTerminalQ string.

so made it enabled/disabled per-user-terminal settings. This means that if
you were already enjoying mouse support, you're going to have to turn it on
to keep enjoying it. It also means there's currently no way to enable/use
mouse support pre-logon, but I have ideas about how to support that for
sysops that want that.

I removed the FTP-download of syncterm.lst from Vertrauen as that didn't work in Win10 for whatever reason.

with the changes to "parse messages from server better".
This change caused the channel's nick array to be populated with a single
string that contained all the Nick's in the channel, space-separated, which
broke tab-completion of nicks and the total users in a channel displayed
in the status line, as reported by Hakuchi.

(e.g. Linux-armv6 for rPi).

we're at it.

definition of ARCHITECTURE_DESC in builds targetting ARM processors.

Add support for %^ command-line specifer which expands to the system architecture (e.g. "i686" for Win32 builds, "x64" for Linux-x86_64 builds).
Currently, there underlying XPDEV macro definition does not differentiate
between arm32 and arm64, but it should. Next...

The msgbase 'status' header created with smb_open_sub() had all its fields
0-filled.
This would cause all kinds of msgbase settings (e.g. max msgs, max age, etc.) to not propagate from their SCFG settings (for mail or sub-boards)
to the newly-created msg base(s).
But most importantly, it would cause the mail base to be created without the
"EMail" attribute flag, causing the msgbase to be treated as a sub-board
(public message area) and users could not then read their received mail.

The root-cause was that smb_open() will zero-out the current smb.status
value before trying to read it from the msgbase header, thus losing any
values that were populated in there before calling smb_open(). Rather than
change the behavior of the ancient smb_open() function, just restore the
correct default smb.status values after calling smb_open() and before
calling smb_create().

automatically revert to Raw/TCP mode. This resolves the issue of users that
connect using modem/serial emulators over TCP that do not actually support Telnet and then either try to transfer files, which usually will not work due to escaped (or unescaped) IAC (0xFF) characters, or the user may be sent Telnet Go Ahead (GA) sequences which may display as periodic garbage in their terminal program.

This seemed like a better solution than having (yet another) dedicated terminal server port for "raw" connections over TCP, though a "raw" port still might not be a bad idea for a future enhancement. RLogin is already super close to "raw", so it's probably not really necessary to have another port configured/listening.

The patch I gave you hasnt applied correctly - I probably should have given you
a unified diff. <sorry>

Can you revert it, and put this text in the "case 'N'" stanza:

this.__properties__.curr_attr=((this.__properties__.curr_attr)&0x8f)|LIGHTGRAY;

So that stanza not only reverts HIGH and BLINK, it also sets the background and
foreground colors back to BG_BLACK|LIGHTGRAY.

regular users (non-sysops), as reported by WitNik (thanks!

An experimental external() mode flag that runs JS modules in their own separate runtime and context - currently does not work (appears to corrupt the shared JS context). Not actually used currently.
The reason I wanted to run a JS module (actually JS doorgame) in its own context was to get useful error messages (filenames and line numbers) when the module throws an exception. Currently, the error is just reported as occuring in xtrn_sec.js, which isn't helpful or correct.