Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in main:
(cherry picked from commit 1d386b48a555)

multiples of 8.  Then the misaligned pixels at the end were not copied.

Clean up variable misuse related to this bug.  The width in bytes was
first calculated correctly and used to do complicated reblocking
correctly, but it was stored in an unrelated scratch variable and later
recalculated with an off-by-1-error, so the last byte (times 4 planes)
in the intermediate copy was not copied.

This doubly-misaligned case is especially slow.  Misalignment complicates
the reblocking, and each misaligment requires a read before write, and this
read is still not done from the shadow buffer.

nonzero height, the first line in the original order was not copied, and
for zero height, garbage lines before the first were copied until a crash
occurred.

screen.  Instead, copy a merged bitmap 1 line at a time.

This fixes flashing of the cursor and is faster in all modes (especially
in planar modes).

VGLMouseFreeze() now only defers mouse signals and leaves it to higher
levels to hide and unhide the mouse cursor if necessary.  (It is never
necessary, but is done to simplify the implementation.  It is slow and
flashes the cursor.  It is still done for copying bitmaps and clearing.)

VGLMouseUnFreeze() now only undoes 1 level of freezing.  Its old
optimization to reduce mouse redrawing is too hard to do with unhiding
in higher levels, and its undoing of multiple levels was a historical
mistake.

VGLMouseOverlap() determines if a region overlaps the (full) mouse region.

VGLMouseFreezeXY() is the freezing and a precise overlap check combined
for the special case of writing a single pixel.  This is the single-pixel
case of the old VGLMouseFreeze() with cleanups.

Fixes:
- check in more cases that the application didn't pass an invalid VIDBUF
- check for errors from copying a bitmap to the shadow buffer
- freeze the mouse before writing to the shadow buffer in all cases.  This
  was not done for the case of writing a single pixel (there was a race)
- don't spell the #defined values for VGLMouseShown as 0, 1 or boolean.

worked right for white interiors and black borders was used).  Advertise
this by changing the default colors to a red interior and a white
border (the same as the kernel default).  Add undocumented env variables
for changing these colors.  Also change to the larger and better-shaped
16x10 cursor sometimes used in the kernel.  The kernel choice is
fancier, but libvgl is closer to supporting the larger cursors needed
in newer modes.

The (n)and-or logic for the cursor doesn't work right for more than 2
colors.  The (n)and part only masks out all color bits for the pixel
under the cursor when all bits are set in the And mask.  With more
complicated logic, the non-masked bits could be used to implement
translucent cursors, but they actually just gave strange colors
(especially in packed and planar modes where the bits are indirect
through 1 or 2 palettes so it is hard to predict the final color).
They also gave a bug for writing pixels under the cursor.  The
non-masked bits under the cursor were not combined in this case.

Drop support for combining with bits under the cursor by making any nonzero
value in the And mask mean all bits set.

Convert the Or mask (which is represented as a half-initialized 256-color
bitmap) to a fully initialized bitmap with the correct number of colors.
The 256-color representation must be as in 3:3:2 direct mode iff the final
bitmap has more than 256 colors.  The conversion of colors is not very
efficient, so convert at initialization time.

code for reading from the frame buffer.

Reading from the frame buffer is usually much slower than writing to
the frame buffer.  Typically 10 to 100 times slower.  It old modes,
it takes many more PIOs, and in newer modes with no PIOs writes are
often write-combined while reads remain uncached.

Reading from the frame buffer is not very common, so this change doesn't
give speedups of 10 to 100 times.  My main test case is a floodfill()
function that reads about as many pixels as it writes.  The speedups
are typically a factor of 2 to 4.

Duplicating writes to the shadow buffer is slower when no reads from the
frame buffer are done, but reads are often done for the pixels under the
mouse cursor, and doing these reads from the shadow buffer more than
compensates for the overhead of writing the shadow buffer in at least the
slower modes.  Management of the mouse cursor also becomes simpler.

The shadow buffer doesn't take any extra memory, except twice as much
in old 4-plane modes.  A buffer for holding a copy of the frame buffer
was allocated up front for use in the screen switching signal handler.
This wasn't changed when the handler was made async-signal safe.  Use
the same buffer the shadow (but make it twice as large in the 4-plane
modes), and remove large special code for writing it as well as large
special code for reading ut.  It used to have a rawer format in the
4-plane modes.  Now it has a bitmap format which takes twice as much
memory but can be written almost as fast without special code.

VIDBUFs that are not the whole frame buffer were never supported, and the
change depends on this.  Check for invalid VIDBUFs in some places and do
nothing.  The removed code did something not so good.

screen bitmap and within a single MEMBUF were broken when first source
line is before the first destination line and the sub-bitmaps overlap.

The fix just copies horizontal lines in reverse order when the first
source line is before the first destination line.  This switches
directions unnecessarily in some cases, but the switch is about as
fast as doing a precise detection of overlaps.  When the first lines
are the same, there can be undetected overlap in the horizontal
direction.  The old code already handles this mostly accidentally by
using bcopy() for MEMBUFs and by copying through a temporary buffer
for the screen bitmap although the latter is sub-optimal in direct
modes.

the same code as the VIDBUF8 case, so it only worked for depths <= 8.
The 2 directions for copying between VIDBUFs and MEMBUFs worked by using
a Read/Write organization which makes the destination a VIDBUF so the
MEMBUF case was not reached, and the VIDBUF cases have already been fixed.

Fix this by removing "optimizations" for the VIDBUF8 case so that the
MEMBUF case can fall through to the general (non-segmented) case.  The
optimizations were to duplicate code for the VIDBUF8 case so as to
avoid 2 multiplications by 1 at runtime.  This optimization is not useful
since the multiplications are not in the inner loop.

Remove the same "optimization" for the VIDBUF8S case.  It was even less
useful there since it duplicated more to do relatively less.

Reading of single pixels didn't look under the cursor.

Copying of 1x1 bitmaps didn't look under the cursor for either reading
or writing.

Copying of larger bitmaps looked under the cursor for at most the
destination.

Copying of larger bitmaps looked under a garbage cursor (for the Display
bitmap) when the destination is a MEMBUF.  The results are not used, so
this only wasted time and flickered the cursor.

Writing of single pixels looked under a garbage cursor for MEMBUF
destinations, as above except this clobbered the current cursor and
didn't update the MEMBUF.  Writing of single pixels is not implemented
yet in depths > 8.  Otherwise, writing of single pixels worked.  It was
the only working case for accessing pixels under the cursor.

Clearing of MEMBUFs wasted time freezing the cursor in the Display bitmap.

The fixes abuse the top bits in the color arg to the cursor freezing
function to control the function.  Also clear the top 8 bits so that
applications can't clobber the control bits or create 256 aliases for
every 24-bit pixel value in depth 32.

Races fixed:

Showing and hiding the cursor only tried to avoid races with the mouse
event signal handler for internal operations.  There are still many
shorter races from not using volatile or sig_atomic_t for the variable
to control this.  This variable also controls freezes, and has more
complicated states than before.

The internal operation of unfreezing the cursor opened a race window
by unsetting the signal/freeze variable before showing the cursor.