Fix age-old bug with Borland/C++Builder built executables (Windows):
to achieve compatibility with  the default __cdecl symbol naming rules of
Visual C++, we were using __stdcall convention for DLL functions when
building code with Borland/C++Builder tools and using the default (__cdecl)
convention when building with Microsoft (Visual C++) tools. Although this
allowed symbols to be located when linking, the calling convention mismatch
caused a stack cleanup issue that very rarely manifested itself in a bug
(e.g. exception of some kind in sbbsctrl.exe, usually). Mismatching
the calling conventions was unintentional (I thought the default for MSVC
DLL functions was __stdcall) - but since the calls to MSVC-Built DLL functions
worked 99% of the time, I didn't realize there was an underlying issue. So I
now work-around the DLL symbol naming mismatch using a command-line option (-a)
passed to implib in src/sbbs3/ctrl/makelibs.bat

I had previously worked-around exceptions when calling MSVC DLL functions in
sbbsctrl.exe by calling the problematic DLL functions from a timer tick handler
rather than a user control (e.g. button) event handler. Those work-arounds can
now be removed.

The erroneous "DLLCALL" definition design pattern was replicated (copy/pasted)
to many other projects' header files in cvs.synchro.net. In the future, we may
want to just remove all instances of *CALL since they now serve no purpose and
appear as useless "Kruft" (but do allow us to more-easily globally change DLL
function calling conventions if/when necessary in the future).

the libmozjs from firefox et. al.

every runtime.

test shared runtimes (which still crashes)

I suspect this is due to the script compilation/startup not being inside
a BeginRequest() block.

SpiderMonkey 1.7