Don't always start with _NET_WM_STATE containing
_NET_WM_STATE_FULLSCREEN

Enable PropertyChange events

Adjust x_cvstat.win* when _NET_WM_STATE gets
_NET_WM_STATE_FULLSCREEN added

Don't disable fullscreen in ConfigureNotify handler when
fullscreen is still pending

Now that I've upgraded my RPi 400 to aarch64, it turns out aarch64
isn't supported by Spidermoney or the libffi it ships with, so
there's no easy way to make it build.

Untill Spidermonkey is updated, there's just no reasonable way to
build on aarch64.

On expose, always redraw the entire screen.  The calculations were
wrong and with fractional scaling, some of them will always be wrong.

Don't clear the screen when xim is resized.

It looks like "armv7l" didn't exist when this version of Spidermoney
was released.  Just expand a previous patch to include all arm*
architectures.

C allows char* p = '\0' (which is clearly wrong)
C++ does not.

format specifies type 'unsigned short' but the argument has type 'unsigned int'

"unary minus operator applied to unsigned type, result still unsigned"

Even though this same code compiled and worked as expected with GCC.

SANITIZE is not fully supported (or recommended) yet.

FORTIFY will include some performance hits, but those might be offset by -O1
(which is apparently required for _FORTIFY_SOURCE to have any effect).
Prevviosly, DEBUG builds used (implicit -O0).
I'm building and running sbbs on Vertrauen (git.synchro.net) now with FORTIFY.

Set FORTIFY=1 in your localdefs.mk if you wish to have this build option
enabled persistently.

I'm doing builds for my jail (which doesn't have libmosquitto) on
my system that does have it now, so I need to disable it manually.

Mostly (all?) about unchecked return values. Unexpected failures to read or
write some files could've definitely led to some weird bugs.

Don't null-deref h_addr_list.
Return in_addr_t instead of u_long.

warning: ‘maxval’ may be used uninitialized
warning: ‘inch’ may be used uninitialized

Don't deref a null pointer and return an in_addr_t instead of ulong.

Was wrong and therefore causing flickering.

Was not using struts, and was scaling to window size, not aspect
ratio size.

Also, reset struts when not in fullscreen mode.

GDI and X11 still can't be *started* in fullscreen mode though.

Win32GDI currently requires two rects to be available.

- Ensure last is cleared even if we manage external scaling without Xrender
- Free the bitmap rectangle in the same situation
- Make a copy of x_internal_scaling so it's used consistently
  (not mutex protected, and accessed from multiple threads)

If there's already an outstanding rectangle when the blinker thread
wants to send another one, skip it.

This keeps the interface responsive at the cost of some skipped
frames.

ChromeOS (as of Jun 2023) effectivly makes PRIMARY useless.  Just
do the wrong thing and use CLIPBOARD instead.  This makes it much
more likely that SyncTERM selections will clobber CLIPBOARD
unintentionally, but we have no choice... DigitalMan doesn't use
X11 mode solely because ChromeOS sucks at X11.

While we're hacking on that, make a first attempt at a generic
Atom access framework.

The only actual visible change that should occur here is that the
window will not resize larger than will fit on the current desktop
between various WM widgets (panels and menus).  I've been considering
this change for a while, but now that fullscreen support is present,
it doesn't really take anything away.

Just use _NET_WM_STATE protocol for fullscreen... messing around
with the methods is pretty painful.

Because we're not messing with other stuff, we can likely remove
all the code I added to prepare for this. :D

Testing this really highlighted other broken bits, so a bunch of
that has been fixed as well... including the bug that Ragnorok
hadn't reported yet as of last time I looked (corrupted screen when
maximixed).