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

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.

A bunch of possible (but often, not really) use of undefined values.
Some ignored return values (e.g. of chsize/ftruncate, read, write, fgets).

Other than some added diagnostics upon some of these unexpected syscall
failures, there should be no change in behavior from this commit.

Mainly capitalization, but some typos and added details. 

to remove all sections in an .ini file or all sections with a specified
prefix.

CID 327965

CID 350276

This resolves errors when setting these properties to values > 2147483647
example:
!JavaScript  /sbbs/exec/load/sauce_lib.js line 69: Error: can't convert
2430770157 to an integer

That means you can now seek around (set position) within files > 2GB, truncate
or extend a file > 2GB, or set a file's date to > Jan-19-2038.

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 319023 319065 319134

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

Still needs updates in services_thread(), CGI stuff in websrvr.c,
and sbbs_t::external()

Documented here: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_05.html#tag_02_05_01
This provides the best chance at read_raw() reading from the right
location and updating the file pointer as expected while avoiding
behaviour which is explicitly undefined by POSIX.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Reverted the SAFECOPY() NULL source-pointer magic "(null)" string thing as that caused a different Coverity issue. Explicitly check for NULL at the call-sites instead.

Hopefully not introducing any bugs in the process.

Hopefully not introducing any bugs in the process.

Doing so prevents extending the prototype.

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()

If an .ini file is read by either the iniGetObject() or iniGetAllObjects() methods and contains a key with a blank value, that property would be created with an "undefined" value.

Both the iniGetObject() and iniGetAllObjects() methods now accept an additional Boolean argument (which defaults to false), to specify that "blanks" are acceptable. When the "blanks" argument is true, then keys with empty values in the .ini file are created as properties with empty string values (length of 0).

This is going to be useful for modopts.js to read potentially-blank strings from modopts.ini and differentiate between a blank string key and a missing key.

I'm fed-up with MSVC assertions in ctype functions (e.g. isdigit, isprint, isspace, etc.) when called with out-of-range (e.g. negative) values.

This problem only affects MSVC debug builds, but if you run them (like I do), these things are like little time bombs that can drive you crazy (knocking your board out of service).

The new macros names are bit more descriptive as well.

iniReadFile():
- enables the use of the !include directive in the read .in file
- reduces rewinds/re-reads of the .ini file, speeding up the total operation

I also removed the old crash dump comments from here.

documented (it says if the section is *undefined*, the root section is read)

iniGetAllObjects() to sort of "normalize" the key names into easily-useable
(and consistent) JavaScript property names.

JS numbers are double-precision floating points (doubles) and doubles cannot
be converted to unsigned integers uniformly across all architectures (e.g.
specifically on ARM, negative numbers would mostly get converted to 0U).

For details, see
https://www.embeddeduse.com/2013/08/25/casting-a-negative-float-to-an-unsigned-int/

Moved some dbprintf() lines around a bit.

If dup() fails, return NULL
If callog() fails, fclose() the new FILE*
No functional change (hopefully).