really no useful way to recover from failure.

This should fix the Clang warning that Deuce reported:
str.cpp:131:18: warning: passing an object that undergoes default argument promotion to 'va_start' has undefined behavior

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

TLS clients don't (currently) add a certificate, so there's no need
to delete it.

Use cryptDestroySession() instead.

With this, it's not strictly necessary to clear cert_list in ssl_sync()
when the certificate changes, but it's still a good idea to prevent
unusable memory from being held onto.

warning: value computed is not used

Now each lock has an easily understandable purpose, and covers the
lowest possible amount of code.

Use new rwlock for ssl certificate.

See merge request !386

Instead of tight loops with 1ms Sleep()s in them, add events for
zero readers and zero writers that we can wait for instead.

Unfortunately, since Events aren't interlocked with a critical section
like condition variables are with mutexes in pthreads, we can't
rely on this for race-free code, so for read locks, we still may
spin under write pressure.

Various bits of broken no longer broken.

Since we can't bool anyway, may as well.

It would be nice to use TLS for the recusrion counter, but on Windows,
it looks like TLS in threads created after the object is created is
uninitialized, so we would need some kind of thread start hook thingie
which just seems like too much work.

Instead, rely on the old standby single-linked list to track.

It looks like Windows actually uses the name for matching existing
events, so if two events have the same name, they end up being the
same object.

Recursive read locks, non-recursive write locks.

Currently the "wrapper" is just the POSIX API.
We may not need the pthread_rwlock_timed??lock() functions, and even
if we do, we like want a different wrapper that takes a ms timeout
instead of an absolute time.

On Win32, the name param is an LPCSTR which apparently is Microsoft
talk for const char *.

In C we're allowed to do whatever we want, but in C++, this matters
more.