e.g. [can|is]_subject_something() is now named subject_[can|is]_something()

No functional change.

The Git commit date/time is more useful information.

Still using BOOL where we need Win32 API compatibility.
Using JSBool instead of BOOL or bool where it matters.
Changed most relevant TRUE/FALSE to true/false too (though it's not as critical).

You shouldn't need to #include <stdbool.h> anywhere now - gen_defs.h should do that automatically/correctly based on the language/version/tool. In C23, stdbool.h isn't even needed for bool/true/false definitions (they're keywords), so we don't bother including stdbool.h in that case.
Microsoft didn't define __STDC_VERSION__ in their older tool chains (even though they were C99 compatible and had stdbool.h), so we use a _MSC_VER check to know that there's a stdbool.h we should use in that case.

For other/old compilers (e.g. Borland C) we #define bool/true/false following the pattern of stdbool.h (doesn't use a typedef).

I didn't convert UIFC yet.

This addresses issue #698

So Clang-FreeBSD was warning (in compiles of scfg/scfg*.c by Deuce):
result of comparison of constant 100000 with expression of type 'uint16_t'
(aka 'unsigned short') is always true

Why? Cause a uint16_t's max value is 65535 (less than 100000). Sure we could
have just lowered the UIFC max number of config items to 65535, but that would
have been too easy. And why are these compared-with values of type uint16_t to
begin with? Because most ctrl/*.cnf lists (of configuration items) were
limited to 65535 entries cause ... 16-bit DOS, historically. Now that *.cnf
files aren't used, we could just increase these scfg_t.*_total type sizes from
16 to 32-bits, yeah? The result is this commit.

I went to (signed) int so we could still keep -1 as the special illegal
sub/dir num value (e.g. INVALID_SUB, which is sometimes used to indicate the
email message base). Theoretically, 2 billion configuration items could be
supported in these lists, but SCFG will limit you to 100000 anyway. So there's
a whole lot of s/uint/int in this commit.

I'd be very surprised if this doesn't result in some new GCC/Clang warnings,
but at least the old "comparison of constant 100000" warnings are now gone!

Avoids crash when adding a msg to a non-sub-board msgbase.

smb_faddrtoa() uses a static local buffer if passed NULL and we shouldn't be
doing that from multi-threaded callers.

Just in case a sysop deletes/changes their addresses after create subs, find the nearest matching configured system FTN address/AKA and use that.

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

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...

Some old/unsupported FidoNet software (NetMgr? Squish?) reportedly parse addresses from MSGID control/kludge lines in NetMail messages to determine the source and/or destination address. This is clearly a bad idea for a lot of reasons, but to improve compatibility, let's not include the message number (or an '@') in the origaddr field for NetMail messages. This does slightly increase the chance of a duplicate MSGID being accidentally generated if the "mail" base is renumbered. No change for EchoMail MSGIDs (where dupe detection and threading still benefit from the additional entropy).
For Watchman.

Recompiling ver.cpp only now, so need link ver.obj/o with the various targets now. I'll need to update the objects.mk for the *nix builds, next.

Allows reporting of branch/commit that was used to build the code.

If for some reason building without 'git', you'll need these 2 files to
already exist somehow - still need to work that out (e.g. for daily
built-source archives).

Need to update the Windows build to generate these files now.

The goal of this commit is that: only modules that either are part-of sbbs.dll/libsbbs.so or need to link with/use that library, will #include "sbbs.h" and thus be dependent on its subsequent includes (e.g. cryptlib.h, jsapi.h). This should mean extdeps.mk can be trimmed way down.

I also removed CVS keyword/comments and trimmed up the boilerplate copyright notice in modified and added source/header files in this commit.

There is no functional change in behavior in this comment.

Move nearest_sysfaddr() from fido.cpp to msg_id.c since it's needed by anything that uses msg_id.c now (e.g. SBBSecho, which doesn't link fido.cpp).

"Other systems produce [FTN MSG-IDs for NetMail messages) quite nicely: HotdogEd, BBBS, Mageia, Platinum
Express, GED+LNX, and OpenXP.   I took it for granted that SBBS would be
in the same league.   It makes it super easy to link up a netmail
conversation or generate a graphical-tree when a msgid exists.

I was spoiled into thinking that msgid was ubiquitous in netmail as well."

Reviewing FTS-9, I see no restriction to only echomail, so sure, why not:
add_msg_ids() now adds FTN Message-IDs to outbound NetMail messages too (not just FTN echomail). No configuration or SBBSecho change needed.

designator.

is 0 (logic moved from sbbs_t::postmsg()).

So I created a single add_msg_ids() function (mostly migrated from postmsg.cpp)
to make this incredibly easy so any/everywhere that adds a message to a message
base should be able to call it. This function also creates reply-IDs (when
relevant) and program ID (Fido-PID) header fields:
- FIDOPID (always)
- FIDOMSGID (if an echomail post)
- FIDOREPLYID (if an echomail reply-post)
- RFC822MSGID (always)
- RFC822REPLYID (if a reply)

message-ID (e.g. when exporting from SBBSecho).
This addresses compliance with this [editorialized] clause in FTS-9:
     No system
     should ever add an MSGID and/or REPLY to,  or modify an existing
     MSGID / REPLY contained in,  a message not originating on that [FTN]
     system.

Messages gated from other networks (technically coming from another system,
but originating into an FTN from this system) will still have an FTN Message-ID
generated/added.

Since SBBSecho normally tosses to downlinks directly from packets, this adding
of generated Message-IDs would no normally occur. However, if a downlink
rescanned an area, any messages missing Message-IDs would get them generated
automatically and they would appear to have originating on the local system.
This was never the intention, so this is just a long standing but infrequently
observed (and never reported) bug.

already have a reply_id header field, causing REPLYID header fiels to be
set to garbage characters.

normal messages along with voting data (polls, ballots, etc.) would always be
imported in this order: msgs, polls, ballots/votes, and then poll-closures.
This could result in a confusing order of messages in the local msg base where
there were messages in reply to a poll before the poll appears and other
oddities. Anyway, this is now resolved by placing a msg "header block" for each
vote-data item in the MESSAGES.DAT file. Since there is no body/text blocks,
it should be ignored under normal circumstances, but these header blocks are
only created if VOTING.DAT is enabled anyway.
And now, the VOTING.DAT contains an extra line (empty .ini section) with the
HEADERS.DAT offset associated with the chronology of the item. The format
is still backwards compatible with the earlier builds that included VOTING.DAT
support.

Also, fixed the vote/poll/closure Message-IDs containing a msg number of 0
(while not technically a problem, it wasn't the intention) with the use of the
new function: get_new_msg_number().

If a message header has a thread_back value (it's a reply to another msg), but
there is no Reply-ID header field, when converting QWK, look-up the
original message-ID (to use for the relpy/vote Reply-ID value). If the original
message doesn't have a message-ID, use the normal auto-generation scheme.
This isn't normally necessary, but I posted a poll with a message-ID on
DOVE-Net / Sysops and then voted on the poll, creating a vote with no Reply-ID
which causes an SMB "writing" error (access=-105) on the QWKnet node BBSes
(because the required header field is missing).

* Parses/consumes QWK headers.dat files
  - No more to/from/subj length limits
  - Extensive header details transferred for each message
  - IP/hostname filters (.can files) are applied to appropriate header fields
  - Code cleanup in the QWK functions
* New functions to read/parse/search filter (.can) files as string lists
  - Performance boost - no need to open/read/close .can file for each message
* More thread-safe Message-ID retrieval/generation (ftn_msgid and get_msgid)
* Better Message-ID generation for misconfigured systems (e.g. no hostname)
! These changes require the latest smblib and xpdev libraries !

(for time and message number) if the index hasn't been initialized.

(stuffed into the "origaddr" field), to shut-up the idiots on FidoNet (e.g.
Maurice Kinal and Paul Westell) that claim that some phantom unnamed software
somewhere has a problem with the extended format.