Hopefully not introducing any bugs in the process.

The new subject line parsing (with quoted-filename support) had a NULL-pointer deref built-in.

Also fixed a few Coverity-reported issues.

Caught by Coverity.

Addresses Coverity's NEGATIVE_RETURNS bug-checker issue.

Identified by Coverity.

As tested and reported in FIDONEWS by Michiel van der Vlist, 2:280/5555, SBBSecho would use the "best match" FidoNet AKA for the originating address when replying to PING netmail messages and not necessarily the original destination address of the ping request. For systems that have multiple addresses (AKAs) that could be considered appropriate originating addresses for the requesting node address (e.g. multiple addresses in the same zone or zone/net), this could cause a confusion for the PING requester.

The create_netmail() function now accepts an optional source (orig) address parameter and the PING response logic passes the netmail's destination address for the reply message's originating (source) address.

I noticed that AreaMgr responses also follow the same logic as PING responses (just use the best-fit AKA, not necessarily the same address as the original request's destination address) - but I did not choose to address that "issue" at this time.

Don't return an error if the node#/node.cnf file can't be opened for all uses of load_cfg() except from the terminal server. This fixes #214 for Tracker1

The previous committed fix/issue raised some additional concerns about this "parity" bit:

Something I didn't notice before from the ZMODEM spec:
"The hex header receiving routine ignores parity."

And looking at lrzsz's zm.c, I see it goes even further and ignores the "parity" bit on the ZPAD and ZDLE bytes proceeding the frame encoding byte as well as in the frame encoding byte itself (so ZHEX, 'B' 0x22 and 0xC2 should be treated as equivalent).

I find it strange that some ZMODEM implementations (e.g. chuck's zshhdr()) would send the terminating LF with the even-parity bit set, but not set the even-parity flag for any of the frame content bytes. And then, expect that the parity flag may be set on incoming hex headers. I suppose it makes sense for 7-E-1 connections, but then the transmitted terminating LF would have had its parity flag set automatically (would not need to be set manually in the code). Add to the mysteries of ZMODEM that will likely never be solved.

Some ZMODEM implementations set the high bit (even parity?) when sending this '\n' terminator.
As reported via IRC:
<Keyop> sexyz: !zmodem_recv_hex_header HEX header not terminated with LF: 138 (8Ah)

Feature requested (?) by u/jumbotronjim on https://www.reddit.com/r/synchronet/:

If the client connection is from a blocked IP address (in ip[-silent].can), but still manages to get through the web server and websocketservice and have their correct IP address reported via Telnet Location, terminate the connection. Seems dubious.

Fix issue reported WitNik (BGGRSCYN) on DOVE-Net:
```
sbbs@raspberrypi:~ $ /sbbs/exec/umonitor -iC
...
sh: 1: /sbbs/exec/syncterm-iC: not found
```

These configuration properties were not previously exposed via JS.

No immediate use/need, but I *almost* did. :-)

"Old style" (e.g. FTN netmail) attachments put the filename(s) in the message subject. Supported quoted-filenames in the message subject (i.e. to support filenames with spaces in them) in addition to the traditional space-delimited filenames. Mixing quoted and space-delimited filenames (for multiple attached files) in a single message subject is supported.

Since on 2.17, pthread_afork() is not in libc, -lpthread must be
after -lcl (library link order issue)

Fixes #211

BIG thanks to Scott Comstock for giving me access to his box to fix
this.

Also change the wording of the -D option to be more descriptive.

The "EchoLists" help menu only worked when you first enter the sub-menu and would get wiped out by subsequent child-menu help text.

Filled out the "Configuring an EchoList" help text.

Fixed issue seen where deleting an EchoList's Required Key didn't set the "dirty config" flag, so saving of changes was not prompted when exiting (if that was the only change made).

Also, it's not technically an option, so remove from the option list.

Fixes the Win32 build.

Done.

At Tracker1's request/suggestion.

jsexec -Itrue
...
Result (boolean): true

More elaborate expressions can be evaluated and white-space included by quoting the "-I expression".

Also, send all cmd-line usage errors to stderr and syntax help to stdout, always (Deuce's request).

Stop lying. Programming is hard enough already.

The extra spaces caused the centering of the cryptlib version to be offset (not exactly centered).

Now the default bar is INT_MAX, so it always gets corrected when
left as default.

This is good.

So here's what we're doing now... we set bar so that the first item
shown in the menu is the lowest index possible that still shows cur.
bar is therefore calculated as the displayed item count minus the
distance from cur to the end of the list.

Yeah, that's the easiest way to explain it.

scrn, showbuf, timedisplay, bottomline, getstrxy

Doing so prevents extending the prototype.

The default character set for outbound mail is now auto-determined (when not explicitly specified for a message) between UTF-8, ASCII, and CP437. The [mail] DefaultCharset setting (which fell-back to iso-8859-1 if blank) is no longer "a thing".

Also: specify 8-bit content-transfer-encoding for the (potentially UTF-8 or CP-437) plain text portion of a MIME-encoded message with file attachment (7-bit was wrong) and pass down the text sub-type (e.g. could be "html") for inclusion in the mime-part header (don't assume text/plain, but still use that as default).

Also: log an error when failing to delete an attached file (e.g. from data/file/*.out).

Some (important) File methods did not support .ini files that used the !include directive because they were using the xpdev iniRead* API (which performs no "pre-processing") instead of xpdev iniGet*.

Impacted methods:
- iniGetValue()
- iniGetKeys()
- iniGetObject()

The other existing ini* methods already worked fine with nested (!include'd) .ini files. It's possible there's a slight performance penalty with the new implementation since the entire .ini file is always read for each operation and previously it was possible that only a few "lines" were read to find the key(s) of interest. However, since .ini files are not typically huge and the iniRead/file-stream method likely read large (e.g. 8-32K) blocks anyway (which is usually the entire .ini file) - I don't actually suspect any observable impact to performance.

This change was needed for the new ctrl/modopts.d support.

Added new method useful for debugging nested .ini files:
- iniReadAll()