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).

This is the last feature that SDL mode provides that X11 mode is
lacking.  I rarely use it myself, but it should be there.

Previously, if there was more than one work area, this would be
an infinite loop, re-reading the first workarea repeatedly.

Reported by Ragnarok (thanks!)

Fix infinite loop in bitmap_drv_init_mode() if scaling results in
larger than max size.

This uncovered an issue in resize_window() which would cause the
screen to be corrupted due to vstat not agreeing to the actual window.

This was ending up using an uninitialized value

It appears its matching based on the class, not the application.
Since this was hard-coded to CIOLIB based on the idea of using
resources to customize all CIOLIB windows, this didn't match the
SyncTERM .desktop file, so ChromeOS assumed it was "something else"

Add yet another ciolib_initial_* variable to set this, and she's
finally good!

Implied by _NET_WM_PID being set, so may as well do it.

Seems like a good idea, should allow WMs to kill hung processes and
stuff like that.

The XSynchronize disablement is the most important here... didn't
realize it defaulted to enabled, which has been slowing down a *lot*
of stuff for a long time... not that there's much left that benefits
from disabling Synchronized XLib except this new terrible icon thing.

This allows X11 stuff to work properly.

Actually install the colormap we create.
Remove the 48x48 icon.

As it happens, ChromeOS completely ignores the X11 icons and instead
does some weird magic to drag the icon .png file out of the VM and
uses that.  Basically, getting the icon to work appears to mean
putting some properly named files into magic directores.

USize was wrong, PSize wasn't set, and PBaseSize was set, but flag wasn't.

Also, set both _NET_WM_ICON and WMHint icon pixmap

It seems whatever WM XWayland uses doesn't actually use _NET_WM_ICON
like pretty much everything else for the last 30 years does, so we
need to go old-school or settle for the default pengion icon, which
offends me personally.

The bracketpaste "bit" was set to 0x16, not 0x10 or 16 as intended.
Erase line would erase the wrong line if the scrolling region didn't
start on line 1.

The sketchiest bit here is removing the uifc -> conio dependency
which, since it needs to depend on conio_sdl now means if something
is relying on that, it will need an explicity dependency...

We'll see what the pipeline says.

"I can't think of a reason I'd want scfg and echocfg to remain windows (gui) programs"
                                              -- Digital Man

While I'm here, hack up some SyncTERM vcxproj stuff (which almost
certainly doesn't work, but since I can actually test it now, I
may as well try)

At the same time, add BD, BE, PE, and PS to the terminfo entry.

Note that it seems this is "normally" detected by seeing if $TERM
contains "xterm" which shouldn't work with SyncTERM (which is wildly
incompatible), but the terminfo source file here:
https://invisible-island.net/ncurses/terminfo.ti.html
Gives us hope in the form of this comment:

https://invisible-island.net/xterm/xterm-paste64.html

Bracketed paste was introduced by xterm patch #203 in May 2005, as part of a
larger feature for manipulating the clipboard selection.  Few terminals aside
from xterm fully implement the clipboard feature, but several copy this
detail.  The names for the extended capabilities here were introduced by vim
in January 2017, but used internally.  In 2023, vim patch 9.0.1117 is needed
to work with this change.

That is to say that it likely won't work on anyone's system today
(except maybe Cyan's), but it may magically start working in the
future... assuming tic supports these capnames.  No real clue there
since there's absolutely no termcap support, and I use FreeBSD.