... kind of as I suspected

gmtime_r() can return NULL

Reverts gen_defs/genwrap craziness.

This whole library is starting to get crufty and could use a room
at a hackathon.

More compatible with C++ that way.

Also, for DEBUG builds, add a static assertion that
sizeof(dst) != sizeof(void*) to catch the most common breakage.

Need to update the parameter names as well.

While we're here, Update strlcpy() to slightly more optimal
FreeBSD-13.3 version.

It builds and appears to run... not actually tested.

Artifacts from the 16-bit DOS days where we needed the large or huge
"memory model" to allocate > 64KB of memory.

There's some GNU make sorcery still needed here to address build errors
(though it does generate a working executable):
/usr/bin/ld: cannot find gcc.linux.x64.obj.debug: file format not recognized
/usr/bin/ld: cannot find gcc.linux.x64.lib.debug: file format not recognized
/usr/bin/ld: cannot find gcc.linux.x64.exe.debug: file format not recognized

This allows me to shorten "Informational" to "Info" and "Debugging" to "Debug"
and be backward compatible with existing .ini files. I think "Info" and
"Debug" are universally known and take up less space (e.g. in SCFG).

_fintfirst() is declared in the Mingw-w64 headers as an intptr_t,
which tracks.  Can't find _findfirst on MSDN, so that's good enough
for me... let's see what the pipeline says.

The definition of vsnprintf as _vsnprintf didn't seem to hurt the build
(as well, for Borland)

The GNU_SOURCE build of this function was (sometimes?) just returning the
string and not actually copying it to the passed buf. This is consistent
with the GNU manpage on strerror_r():
"This may be either a pointer to a string that the function stores in buf ..."
but was inconsistent with all the other build types of this function.

Also updated to use strlcpy and write the problematic error number to the
default string (if unknown).

Fixes Coverity issue.

Whill this is perfectly legal and is not a problem, Coverity complains.

Bugfis:   Be sure to terminate value if returning deflt.
Paranoia: Terminate value if iniGetString() returns NULL

I think the only way to trigger the paranoia is to pass NULL as the
default when reading a key that's not present.

OpenFile() returns HFILE and is sus, CreateFile() is more complex,
but returns a HANDLE (and is what MSDN suggests I use).

This is why I returned ret. :D

Fix incorrect Coverity issue that speculates this may return fval.