Fixes OpenBSD build issue.

Does not fix the NetBSD issue, but should be done anyway.

commit it.

Also, a couple new patches for a previous commit that I apparently
hadn't added.

Transposed the order of parameters in commit 09d085e3. Oops.

This should be made palette-aware as well, but since the current
consumer doesn't modify the palette, it's good enough for now.

Still a bunch more work to do on labels... sizers come next.

It appears that after successful completion of a JS service, the
TLS session is never destroyed.

If this fix isn't valid for #707, we should see a bunch of
"Destroying a session (...) that's not in sess_list" log messages

Thanks Keyop!

Previously, we compiled in a RGB -> YCbCr table and used that for
scaling, which added 128MB to the size of binaries that enabled
non-integer scaling.  The decision was then made to eliminated
non-integer scaling support from the Synchronet utilities to save
disk space.

With the use of the YCoCg-R, we can more efficiently transform between
the colour spaces, (about 50% more CPU than using the table), so
it's no longer prohibitive to do this in real-time.

This should also have the effect of making the Synchronet utilities
use the correct aspect ratio for the various screen modes rather
than forcing the use of square pixels.  I expect DigitalMan will
hate that.

It seems to provide similar perceptual results, and is much faster
to transform with RGB.  It's still slower than the table lookup,
but not crushingly so.

I think this is ready to start drawing things soon now.

Fix a typo in help text.

Getting design to completion... just need to figure out how to do
pre-defined trees of controls, and I should be able to start work
on the actual rendering bits.

It's expected that transparency will be handled by special values.

Start hacking on fit-checking code
Add NI_walk_children() to call a callback for each child
Move functions that have no generated bits into newifv_nongen.c
Call the object set/get function for globals to allow range checking

Basically, the intent is to do a modern (for C) interface which
allows reproducing the look and feel of uifc but without hurting
as much.

The intent is to support a tree of objects, each of which have
an attribute get/set function as their main interface.

Various callbacks will be supported for various object types, and
positioning will be relative to the "child area" of the parent.

The SyncTERM main screen is expected to look something like:
root
+--frame (dialing directory)
|  +--list
+--frame (settings)
|  +--list
+--textinput (comment)

Internally, the code is wildly type-unsafe, but there's an
auto-generated API (which is the only thing exported) that is
type-safe.

This also introduces the CuTest C test suite as an experiment.

... and rearranged them to match SCFG->System->New User Values->QWK Message
Packet Settings more closely.

uedit (the program) should be updated too.

Silly me, this is C++, do the C++ thing

No functional change.

Seems a useful function to have on hand. Especially now that it's "fixed"
(will convert "1234" to "1,234").

I noticed while testing the previous commit that 4 digit values weren't
thousands-separated, while larger values were. I'm not sure why this
non-zero index check was in this loop, but appears to be a bug.

- bbs.expand_atcodes() now supports formatting (did not before this)
- text.dat/ini strings now support @-code formatting (did not before this)
  (this fixes issue #697)
- bbs.atcode() now supports more complete formatting (only supported -R/-L
  previously)

The -W (wide) formatting code is not supported in these cases since that code
currently sends UNICODE sequences directly to UTF-8 terminals, when used.

sbbs_t::gettimeleft() was storing a pointer to a stack (temporary/local)
variable containing a copy of the next exclusive event cfg (including its
internal code). This variable, including the internal code, is invalid when
it goes out of scope. This change makes the sbbs_t::event_code point to the
sbbs_t::cfg.event[]->code (on the heap) instead.

The only use of this event_code (outside of the event_thread), appears to be
in the JS bbs.event_code property string. So this fixes issue #705. No other
observed side effect from this bug.

Constified getnexteventtime() while here. No functional impact.

Fixes issue #704 - not just for JS bbs.edit_msg(), but for all uses of the underlying sbbs_t::editmsg() function.

Replaced one specific comparison of subnum == INVALID_SUB with call to is_valid_subnum() just to be consistent. No functional change there.

Conditional jump or move depends on uninitialised value(s)
   at 0x4AE768D: sbbs_t::backfill(char const*, float, int, int) (con_out.cpp:1445)
   by 0x4AE7855: sbbs_t::progress(char const*, int, int, int) (con_out.cpp:1467)
   by 0x4AE91A9: ProgressLoadingMsgPtrs(void*, int, int) (data_ovl.cpp:27)
   by 0x4C7C577: getmsgptrs (userdat.c:3972)
   by 0x4AE9144: sbbs_t::getmsgptrs() (data_ovl.cpp:39)
   by 0x4BF9237: sbbs_t::logon() (logon.cpp:452)
   by 0x4AC1CE2: sbbs_t::answer() (answer.cpp:636)
   by 0x4C0FD37: node_thread(void*) (main.cpp:4277)

Introduced in commit 48e7520e (when colors was converted from a byte array
to a uint array), we weren't memsetting the right number of bytes.

Since color is not an array of ints (not bytes), memset (of non-zero values)
isn't really the right initialization approach anyway. Now using a for-loop.

But continue initializing/running for other non-TLS protocol support.