Should calm the clang warnings reported by Deuce:

e.g.
passing 'char *[18]' to parameter of type 'const char **' discards qualifiers in nested pointer types

Replaced _property_ver_list (array of numbers) with _property_ver_list (array
of objects) with a "ver" and (optional) "desc" property. This solves the
enumeration order problem with objects that have both manual and table-based
properties. Object's property tables (arrays of jsSyncPropertySpec) can now
(optionally) contain the property descriptions. For properties defined in this
manner, there will never be another mismatch between ther name/type and
description/version in the jsobjs.html (a problem has re-occurred several
times through the years with nebulous work-arounds).

We still use _property_desc_list arrays for additional (e.g. manually defined)
properties in such objects or just objects that only use one method of
property definition and are not subject to the enumeration order problem.

Fixed numerous typos.

Using more consistent terminology and HTML mark-up.

Some beautification and enhancement of readability, but nothing too major.

Mainly capitalization, but some typos and added details. 

CID 319135

CID 319142

CID 319142

This macro has expanded to nothing for a while now and even before, the usage was misguided and unnecessary as explained in this video: https://www.youtube.com/watch?v=cjotPqQxxAY

CID 33260

This won't impact Synchronet as it has a separate signal handling
thread, but we still need to behave properly for processes that
don't.  I'm also saying that ENOMEM does not indicate a disconnection,
though it may be better to pretend it was disconnected...

It appears when this module was created it was copied from js_socket.c and
the use of ERROR_VALUE (which is socket-specific on Windows) was not corrected.

declaration

Use this in place of JS_GetPrivate() in native class methods that need the
class instance's private data pointer and will do bad things if that pointer
points to something other than what is expected. mcmlxxix (matt) discovered
that using Object.apply(), you can invoke class methods where the 'this'
instance is a different class. This would result in
"Internal Error: No Private Data." or a crash.
So now, gracefully detect this condition and report a meaningful error:
"'<class-name>' instance: No Private Data or Class Mismatch"

Also, important to note: if the method uses JS_THIS_OBJECT to get the JSObject*
to pass to JS_Get*Private, then it must do this *before* it calls JS_SET_RVAL.

From jsapi.h:
 * NB: there is an anti-dependency between JS_CALLEE and JS_SET_RVAL: native
 * methods that may inspect their callee must defer setting their return value
 * until after any such possible inspection. Otherwise the return value will be
 * inspected instead of the callee function object.

The js_crypt*.c files still need this treatment.

HANDLE_PENDING() contains a return, so it's theoretically possible that the
memory allocated by the previous JSVALUE/STRING_TO_... allocation could
be leaked. So now we pass an optional pointer to HANDLE_PENDING() which will
call free() on it if it's not NULL, and then sets it to NULL for good measure.

function where the error is being reported from. So the WHERE macro now
contains the __FUNCTION__ "macro" and the various js*.c files that use the
WHERE macro to report errors had to be updated too.
Also, the 'access' argument is now being passed as a signed long rather than
unsigned long. Status/return values are often passed in here (e.g. from smblib)
and may be negative. This argument was being displayed with %ld but wasn't
being passed in as a signed value, so on 64-bit long systems, negative numbers
were just printed as large (4M+) numbers.
Also, no need to call getfname() in errormsg() since this is embedded in the
WHERE macro (since 2009).

or 'longs'. Amazing that no one noticed.

Nobody should notice a change unless their JS is broken.

resolve callbacks.

functions when an excpetion is pending.

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

When a minimum number of parameters is specified in the method spec, this
shouldn't be required, but overkill is better than underkill.

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.