add_poll() method now sets the when_written/imported time stamps and zones
as needed and configured.

(new header properties: upvotes and downvotes), regardless of the
"include_votes" argument value (default: false).
get_all_msg_headers() reads the entire index already, so there's really no
performance penalty unless there are actual votes (and even then, very low).
The MsgBase.get_msg_header() function will *not* return these vote totals since
that would incur a pretty substatial performance hit on that function.

(like save_msg), except you only need a few properties, in order of importarnce:
attr: you need to have this set to MSG_UPVOTE, MSG_DOWNVOTE, or MSG_VOTE
thread_back or reply_id: either of these must be set to indicate msg to vote on
from: name of voter
from_net_type and from_net_addr: if applicable

- get_msg_index()
- get_msg_header()
- get_all_msg_headers()
these functions all accept a new (optonal, last) bool argument "include_votes"
which defaults to false. So if for some reason, you want to load votes, just
pass an additional 'true' argument.
ToDo: polls and vote tallying.
At least for now, existing JS stuff that uses the MsgBase object won't get
messed up by the new voting messages.

MsgBase.save_msg() method. The bug was that it was forcing the idx.to value to
0 which would only work (in theory) for mail going to a QWKnet hub.
Now, save_msg() will check the 'to_net_addr' property of the header object
(or recipient objects) and actually verify that it/they are routeable QWKnet
address(es) and throw an exception if not.
If the first hop is a QWKnet node, sets the to_ext (and thus, idx.to value) to
the account number of the node. This also looks up full-routes via the
route.dat and replaces the to_net_addr value with the full route if necessary.
I guess nobody (including me) tried sending QWKnet netmail via JS before.

MsgBase.get_msg_body() method: added an additional boolean argument (following
the 'include_tails' argument), which defaults to false (disabled). Pass true
for this argument to enable this feature. Yes, JS-authors could do this parsing
easily via JS, but I figure so long as this feature is in the SMBLIB, might as
well expose it to JS for consistency (e.g. in 3rd party message reader mods).

It turns out there was actually a reason to use the macro (fewer arguments).
Oops.

compatibility macro - no functional change.

if one isn't specified.

For backward compatability with versions before 3.16c, this argument should
still be provided.

The get of thread_orig would succeed, leaving val as undefined so the get of
thread_back would never occur.  Testing *after* this for null or undefined
would result in thread_back never being set in the parsed header.

variable (with various race conditions). This resolves a long LONG standing
bug that caused crashes when shutting down or recycling servers/services
while one or more servers/services were in use.
This change requires every thread which calls into libjs to have its own JS
runtime.

this one really does use the message number now.

by offset.

functions.

of the first message in the thread, or 0 if unknown (e.g. legacy message). When
a new message is created, the thread_id value of the message being replied-to
will be used, else if the new msg is not a reply, then the new message's number
will be the value used for the thread_id.
This "thread-id" feature (Deuce's idea) allows threads with a common parent to
remain logically grouped after the original messages in the thread have been
purged (though the original hiearchy will start to be lost).

NULL because the get function is called on the prototype which isn't
constructed (via the constructor).

client can read the associated message.

Should make moderation/view own deleted/etc handing way easier for JS
developers.

MsgBase.get_msg_tail() which will optimize the get to avoid re-reading
the headers.  When this is specified, the message number or id is not
required (but specifying it won't hurt anything and will allow backward
compatibility).

I'm not sure I need to lock the header here, but I think I might (if nothing
else, to ensure the message still exists).

to expose via JS: sender_userid, sender_server, and sender_time.

resolve callbacks.

value, some fixes).

code.

functions when an excpetion is pending.

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

Perviously, if the argument to a number of bbs.* functions was not a valid
number, Synchronet would silently ignore the parameter and treat it as though
it was not specified.

The new behaviour was to use the value as a number.  However, the old code
caused the exception triggered by an inability to convert the number to
be pending until after the return (the JS_Native didn't return JS_FALSE) so
a try/catch block aorund it would not catch the exception.

The new new behaviour is to throw the exception immediately so it can be
caught and handled correctly.

signed ints such as the zone offset.

Foxes bug with commitlog.js

Only js_ValueToStringBytes() still leaks.