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)

that MSVC RTL functions will not terminate the program (e.g. jsexec, sbbsctrl)
if an invalid parameter is detected (e.g. unsupported format specifier in call
to strftime()).

counter/limits as branch counter/limits.

slightly improved JSDOC descriptions.
Updated JSDOC description of the 'js' object to be more general.

back into the container because str_list_t's tend to realloc()

global object exits.

This fixes a problem where the terminal server reuses the same global object
for all JS scripts, and they uses nested exec()s.  When the innermost script
would exit, the on_exit evals would occure in IT'S scope rather than in the
scope it was defined in, resulting in incorrect behaviour.

is to periodically call JS_YieldRequest from an operation callback."

resolve callbacks.

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)

functions when an excpetion is pending.

Some work still needs to be done on js_msgbase.c,  js_user.c, and mailsrvr.c

Only js_ValueToStringBytes() still leaks.

      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.

js.gc_counter, js.gc_last_bytes, js.bytes, and js.max_bytes
Since these properties rely on internal JS context structure offsets, they're
not always compatible with replaced (upgraded or downgraded) JS library
(shared object or DLL) and can cause crashes in some cases. They can be
useful in some debugging cases, so I'm leaving them in the debug build, but
use with caution.

value of js.auto_terminate (e.g. the irc.js could not restore the original
value, thus re-enabling auto-terminate upon exit of the IRC client).

but run with a different version of libjs.so.

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

than dynamically allocated string list. Also, allow a blank JavaScriptLoadPath
to be specified in the sysop's sbbs.ini if they wish. This resolves the memory
leak issue with this startup parameter.

created:
js.exec_path - full path and filename of file executed
js.exec_dir - directory of executed file
js.exec_file - filename executed (with no path)

Configurable via ctrl/sbbs.ini file JavaScriptLoadPath key value
(comma-separate listed of search directories), default value is "load".
This list is exposed in the JS object model via the js.load_path_list array
(may be modified by scripts).
For JSexec, the default load path list may be over-ridden with the '-i' option.
For relative load paths (e.g. not beginning with '/' or '\'), the path is
assumed to be a sub-directory of the (configurable) mods or exec directories
and is searched accordingly.
So, by default, load("somefile.js") will search in this order:
mods/load/somefile.js
exec/load/somefile.js
mods/somefile.js
exec/somefile.js