I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

I noticed that when executing an external JS with the new "Use Shell / New Context" option set to "Yes", that any expressions (strings) installed via js.on_exit() were not being executed upon exit from the script. These on-exit strings are important for restoring global state information (e.g. control key pass-through, console mode) to the original state before the JS mod made any changes.

I'm not sure why the special treatment of "scope == NULL" is through-out this function. Going back to v3.16, it appears this was special treatment for JS mods invoked via global hot key event (when scope != NULL). When invoking an xtrn JS mod with the new Context option, the scope argument is not NULL, so this check was defeating the parsing of the "exit_code" and the evaluation of any js.on_exit() installed expressions for no apparent reason. I can't think why global hot key events should be excluded from this logic either.

Rather than introduce yet-another-external-program/config flag to enable
the "new JS run-time/context" per invocation of any particular JS command,
I'm using the XTRN/EX_SH ("Use Shell") option as it had no function for
JavaScript command-lines and the concept is similar.

So if you want to invoke a JS external program/timed-event in its own
"sandbox", enable the "Use Shell / New Context" option for that
program/command in SCFG. There may be performance penalties when running
JS mods in this way, but you get the benefit of isolating one JS module
from all others, if/when necessary.

So revert the order back to the way it was in aa2bcd61
(don't you love these git references?).

Also, the previous fix for js_execfile() calls for global hot-key events also
fixed the EX_JS_CX feature I was working on (js_execmodule)!

As reported by Ragnarok and The Lizard Master, invoking a JS global
hot-key handler (e.g. hitting Ctrl-U or Ctrl-P with the privatemsg
or nodelist modules installed as handlers) would lead to the global
object being cleared/corrupted so other scripts would then fail to
run correctly (e.g. Error: can't open sbbsdefs.js: No such file or directory)

This probably explains the JS_GC/JS_ENDREQUEST change needed when
the hotkey-specific JS runtime/context/scope was introduced last year.
Should revisit that too.

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.

- User Defaults menu mousified
- When all hot spots have scrolled off the screen, clear the hot spot list
- Insert new hot spots in the front of the list so they will take precedence
  over any previously defined duplicate hot spots
- Numeric hot spot commands end in a carriage-return
- No auto-acceptence of numbers when there are keys in the keyboard buffer
- Baja UNGETKEY function now inserts keys into the "front" of the keyboard
  buffer (next to be consumed)
- Hot key @-code command text supports C-style escape sequences
  (allows encoding of ctrl chars, spaces, etc.)

- hot spots are clickable screen areas (e.g. in menus and prompts) that   generate key-strokes
- commands may be from 1 to 127 ASCII-characters in length
- currently using the X10 mouse reporting mode, may change
- all mnemonics strings (~Example) are automatically hot-spots
- The new ~ @-code defines a hot spot
- Any screen-clear operation clears all hot spots
- sbbs now tracks the current screen (cursor position) row
- eliminated the old "tos" (top-of-screen) boolean (row == 0 indicates "tos")
- created an sbbs_t::ungetstr() method
- keep track if in pause (hit a key) prompt, for special mouse behavior

new JS console object:
- row property
- tos property is now read-only (and deprecated)
- new methods:
  add_hotspot()
  clear_hotspots()
  scroll_hotspots()

redrwstr() gets some UTF8 touch-ups as part of this commit. <shrug>

together to keep things atomic:
1. Eliminate eprintf() as sbbs_t::lputs() and sbbs_t::lprintf() do the
   "right thing" (e.g. log to the event log when called from the event_thread).
2. Moved upload_stats() and download_stats() from ftpsrvr.c to getstats.c where
    I plan to make use of them for JS-based upload/download file support.

running a JavaScript module would crash (e.g. segfault) sbbs:
Create and use a separate JS runtime, context, and global object/scope for
global hotkey events. This means that the hotkey won't benefit from any
previously loaded/required scripts, possibly effecting the performance of the
first invocation of the hotkey handler. Subsequent JS hotkey events will reuse
the same runtime/context/global, so they'll execute fast(er).

One questionalbe change to js_execfile():
With the JS_GC (garbage collection) call *before* the JS_ENDREQUEST() call, the
process would crash in libmozjs. Moving the JS_GC() call to *after* the
JS_ENDREQUEST() resolved this issue and I'm not clear why. This 'js_cx'
parameter here is not always sbbs_t::js_cx. When called to handle a JS hotkey
event, it's sbbs_t::js_hotkey_cx, so it shouldn't interfere with the
sbs_t::js_cx being used by the currently executing JS module (shell or door).
<scratches chin>

Hopfully this doesn't break the Borland or Watcom (?!) builds.

return an error value (-33, it's the magic number).

network hub call-outs and timed-events.

exec.cpp:438:8: error: case value evaluates to 2684500526, which cannot be narrowed to type 'int32_t' (aka 'int')
      [-Wc++11-narrowing]
                case 0xA0023A2E:
                     ^

The switch cases were unsigned, but the passed value was an int32.

module. This is a reversal of the revision 1.102 commit (Jan-2-2016), but only
for Baja (JS is left with the new behavior). As the commit message said
"We'll see", and what we saw was that the yesnobar.bin and noyesbar.bin
long-standing Baja modules no longer returned "No" when the user hit Ctrl-C.
So at least for now, we have different behavior with regards to the console
abort (ctrl-C) flag between JS and Baja. :-/

blowing up unexpectedly because of load() or a global hotkey event.

This solves the problem of a JS-external program (e.g. SyncWX) being aborted
at a pause prompt with Ctrl-C or Q and that abort status propagating back to
the external program's menu. If there is a module which needs to propagate
the console-abort status up to the parent(s), then this could introduce a
problem. We'll see.

Don't report a JavaScript warning ("Disconnected") until the OperationCallback
has been executed 10 times with the user offline. This gives the executing
script ample time to recognize the disconnected state and exit gracefully.
Script that do not check/notice that the user has disconnected will still be
auto-terminated (by default) and this warning will still be logged in those
cases. The value 10 was picked at random and appears to work fine.

New Features:
- Multiple bindings for each service
  Use comma-separated interfaces on Interface= lines in the ini file.
  Default is now "0.0.0.0,::"
- IPv6 support
- TLS support for the webserver and (non-static) services
  New TLS option in services.ini (ie: Options=TLS)
- Decrease LEN_SCAN_CMD to 35 chars, increase the CID field to 45 chars,
  and rename the MAIL_CMD string to IPADDR.  I think this frees up the
  note field for SysOp use.

scripts global scope (as opposed to js.global which is the instance global
scope), and having exit() define exit_code in js.scope instead of js.global.

This also sets exit_code in js.scope to null when preparing to execute a new
script.  If a new script starts in the same scope as an old one, the old
exit_code value will be destroyed.

This should only impact scripts where js.global != js.scope (bbs.exec()ed,
and mailsrvr)

calling any JSAPI functions.

has its own functional "too much recursion" detection.
Replaced "branch callback" stuff with "operational callback".
JavaScriptBranchLimit has been replaced with JavaScriptTimeLimit
(default value: 24 hours)

      on the floor of Deuce's computer room
Cyan: Rob's on his way
* Deuce throws his coffee on it.

Last commit before stuff starts to break.

are now executed with the node's global object as the scope of the script.

executed via exec_bin() - this had the side-effect of causing background loaded
threads to terminate when the script terminated (rather than when the node
context was destroyed) and also caused the node context to be unused
(for mcmlxxix).

Updated copyright dates.

make system.matchuserdata return an array of all matches if match_all==true, starting at usernumber if specified. (userdatdupe now takes an additional paremeter)

(potentially) non-blank for external JS modules configured in SCFG->External
Programs, as well as those executed from jsexec. If the startup_dir is
specified in SCFG and no path is given for the .js file, it will look in the
startup_dir first. js.startup_dir will be an empty string for all other cases
(currently).

is most likely a memory hog slowdown on everyone elses system, but it works
great for me and is fast and easy!

EX_STDOUT, defining EX_STDIO (to be both STDIN and STDOUT), adding XTRN_CONIO
and EX_CONIO (for future cioxtrn/doorway mode on Windows), change IO_INTS to
XTRN_STDIO

inserting (long) typedefs to prevent warnings, but in the case of the JS File()
class, actually supporting file lengths > 32-bit.

as single argument (strip quotes too?).