This has only ever worked briefly, and makes the code more confusing.

Also, change the terminal type reported to "Beeb7"

This is almost exactly like Prestel, but it's for BBS Micro BBSs
such as BeeBS.  The basic changes are:
1) Moving off the bottom of the screen scrolls instead of wraps
2) BBC Micro "high ASCII" is supported
3) Return sends \r, not #

To support the high ASCII, I actually implemented the ITU-T Rec.T0101
G1 set, which means the smooth mosaic characters are theoretically
available.

However, the SAA5050 emulation clobbers this by "correctly" turning
them into "blast-through" alphanumeric characters.

Doing this required the separated mosaic support be moved into the
font rendering and out of the font itself.

Anyway, the Sysop of beebs.ddns.net should be happy... and since
this will advertise a terminal type of "BBC Micro", they should be
able to auto-detect between ANSI and BBC Micro during login so the
user doesn't need to enter it.  Hit me up on IRC if you want help
with that.

Indenting lib and dir lists use the ul tag, I'm sure this isn't technically the
most correct way to do this, but its providing the cosmetic result I want.

Should make DigitalMan happy by making help output be in the console
on Windows with syncterm.com.  Hopefully syncterm.exe doesn't get
the help output hosed by this.

Also, if the output mode is ANSI, don't require a key press to exit.

This means the crappy 40-column status line can be used!

Assuming I'm right that is... if I'm wrong, this is merely what they
look like in SyncTERM today.

It's just a broken copy of engtest.pst

Keyop provided a video of flashing stuff for me.  This now
synchronizes with that video.  Can't get any better than that.

The warning suggests that x1 and y1 may be uninitialized in the i > 0
block, but that's not really possible...

It's too bad the warning doesn't clarify.  It's also weird that the
warning was in the draw_line() call and not in the lines above that
(incorrectly) compared them with -1.

Fix that check while we're here.

Top-right quadrant doesn't need a quadrant angle, the angle is what
we want already.

It appears that it flashes at 1.5Hz with the off period synchronized
to the blinking text off period.

Still no idea what generates it though.

No functional change

Whoops, missed this from the previous commit.

But testing the pipes for jsexec crashes too, so that's not a bad thing.

Messages posted to sub-boards via SMTP normally will have the recipient
name/address as the "To" (RECIPIENT) value of the posted message. If the sysop
wishes to replace this string (for all SMTP-posted messages) with a different
string (e.g. "All") this is the setting to allow that.

I do want web-scrapping spammers to collect the 'to' fields for my TLDR and
Coverity-scan posts and post their own spam messages via email (any more).

Also accommodate the new link list API (long -> int).

so the sizes of these elements are the same across all our current target
platforms

Fixes race condition/possible crash in listAddNodeData(), listAddNodeString()
and listAddNodeList(). These functions were modifying the node->flags *after*
a node was added to the list and list lock released.

This is most likely the cause of the issue caught by valgrind when running the
jsexec-testsuite:
https://gitlab.synchro.net/main/sbbs/-/jobs/498286

Thank you Deuce and valgrind, nice catch!

The only difference appears to be the column the 1 is in the ¼ character.

Section 2.3.1 is the C0 set, which "is not stored or displayed"
Section 2.3.2 is the C1 set, so interpret "all control characters"
in this context as meaning "all C1 characters".

This "feels" more like what the spec means.

This is the unicode replacement character, now displayed whenever
a G1 byte is received (byte values 160-255).

Prestel terminals are 7-bit devices, and use special escape
sequences to select alternate glyphs.  The Videotex standards
define a default G1 set though, which I am not supporting in the
1.x versions.  So that sysops and users know "something weird
happened", this weird glyph will clearly indicate that.

The C1 characters (128-159) I am supporting though simply because
it's easy to do, and I saw at least one BBS using them.  These BBSs
won't actually work with a real Prestel terminal though... they may
end up as parity errors, or they may end up as C0 bytes, or they
may be replaced with a '?'... I've seen all three now. SyncTERM can
at least do the right thing since it's well defined.

This may also fix held mosaic display for unhandled C0 bytes... it
looks like previously they were ignored, but the Prestel Terminal
Specification clearly states that "Generally all control characters
are displayed as spaces"... it doesn't limit them to supported
control characters.

At the same time, fix an old error in prestel_handle_escaped() that
didn't pass the ctrl to prestel_apply_ctrl_after() properly, and
always flush the print buffer before calling prestel_handle_escaped()

We still shouldn't actually get C1 characters on a Prestel connection,
but if we do, at least we're doing the right thing now.

As for G1 characters, the default repetoire for these terminals per
ITU-T REC. T0101 is the mosaic character set with smoothed moasics,
something there's no evidence of a Prestel terminal ever supporting.
In order to implement those properly, I would need special handling
of "separated" in the renderer, and would need to fiddle with the
font to include the contiguous smoothed mosaics (and exclide the
separated ones).  Since this would end up allowing wildly un-Pretel
behaviour (ie: mosaics without a mosaic escape) I'm inclined to
just treat them all as spaces and move on util/unless I do full
support for all the Videotex standards.  Nobody has asked me to
open this can of worms, so I'm just going to leave it on the shelf.

Blinking text is opposite of the cursor

For "PC" modes, cursor blinked at 1/16th of the VSYNC rate, so use
the CGA timings, where were generally the slowest of the bunch...
This means cursor blink at 3.745Hz, and character blink at 1.8725Hz.

For Prestel, character blink was 0.75Hz with a 3:1 On:Off ratio.
The cursor on the other hand was 1/32th the VSYNC and was generally
PAL, so 1.5625Hz.

I still need to dig into C64 and Atari modes, because they're likely
way off now (assuming either supports blinking).