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.

Previously, delete lines would erase the line above the current one.
This was visible in vim which makes extensive use of delete line
to scroll.

In theory, this will allow higher quality scaling in GDI mode if
the graphics driver supports it...

It doesn't look like the drive used for VirtualBox does though, so
I can't tell if it does anything or not.

Use the default visual and depth instead of "best"
Use Xrender for sclaing when library is available and server supports it
Set VisualIsRGB8 when possible

This should prevent programs using rgbmap (ie: SyncTERM) from
having an exectuable stack on Linux.

- getscaling() incorrectly used an int intermediate variable
  This would force scaling to an integer value when read.
- Only parse ConfigureNotify events describing a change to the SyncTERM window
  It appears that XWayland on ChromeOS was occasionally sending a
  ConfigureNotify event describing some other window to SyncTERM,
  and that window had a 1x1 size, which would cause SyncTERM to
  assert minimum size again (usually 640x480), which would set
  scaling to 1.0.

1) In savescreen(), if the vmode is not found, explicitly set
   pixels to NULL rather than leaving it uninitialized.
2) Ensure that currmode is never left as _ORIGMODE (which is not
   a defined mode, so can result in vmode not being found).

There's no good argument for this aside from "it feels more right".

Properly initialize sixel mask width/height.
Free sx_mask->bits when finished.

These were broken by the PPM feature commit 6f97dfce

This mirrors commit 1dc4c22a about a year ago that optimized window
dragging, and performs basically the same check (removed a week ago
with commit a59aba35)

Now that bitmap_drv_request_some_pixels() just calls
bitmap_drv_request_pixels(), there's no point in calling expose_rect()
when ev->xexpose.count isn't zero.

- Only call cb_flush() if a new rect was queued.
- Ensure bitmap_drv_request_some_pixels() is only called once in
  response to an expose request.

This should fix issue #565.

Also, do not try to display frames where the scaled height or width
is less than the frame bitmap height or width.

sdl_getscaling() does not require vstatlock.  Move it out.

Currently useful only in GDI and SDL modes.  The external scaling
method is likely lower CPU utilization and may or may not look
better.

All bitmap drivers now support arbitrary scaling, and the scaling
factor is a double, allowing arbitrary window scaling in all bitmap
modes (making nelgin happy).

While we're here, fix bugs in horizontal interpolation and X window
resizeing.

Nonrelocatable const data goes in __TEXT,__const apparently.
I could put it in __DATA,__const and get an entry in the GOT, by
why bother?

For graphical modes, this requests that ciolib be initialized in
the specified mode.  For text-based modes (ANSI, Curses, Win32 Console),
this is not used and "current" is used instead.

Now that vstat is what was last drawn on the screen we need to
save/restore the width/height around calls to bitmap_drv_init_mode().

Win32 rgbmap.s is different than other platforms, so they can't go
into the same place.

This is just to make it less noise to watch vstat.scaling from gdb.

Seriously, that's not possible.