open https://gitlab.synchro.net/main/sbbs/-/issues/672

In theory, running 'jsexec -l -r ;' in a loop, should have a flat memory utilization, but (on Windows, at least), it continually increases "private bytes" memory consumption until eventual exhaustion of virtual memory available to the process.

There have been other observations/complaints pointing to possible memory leaks in sbbs, but nothing as concrete as this particular test.

The same test run on Linux showed a flat memory utilization (no leak observed), though there have been other observations to point to likely memory leaks in the Linux builds of sbbs, e.g.
$ sudo ps v $(pidof sbbs)
PID TTY STAT TIME MAJFL TRS DRS RSS %MEM COMMAND
4171815 ? SLsl 600:40 874 43 11902144 2170904 6.6 /sbbs/exec/sbbs d

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4171815 sbbs 20 0 11.4g 2.1g 8872 S 4.7 6.7 10,00 sbbs

Additionally, it's been observed that running a "JSDOC" build of sbbs results in very obvious/extreme memory leaks over a short period of time (e.g. full memory exhaustion in a matter of days), at least in the Windows build.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

https://gitlab.synchro.net/main/sbbs/-/issues/672#note_4527

Experiments have some that calling JS_NewRuntime/JS_DestroyRuntime is a memory leak on Windows, but not an Linux:

```
while(1) {
JSRuntime* rt = JS_NewRuntime(maxbytes);
assert(rt != NULL);
JS_DestroyRuntime(rt);
}
```

The same experience on Linux-x64-gcc, doesn't leak any memory.
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)