This is a regression from ad0f061. If a VMware cursor rect was split up
over multiple read()s then the stream would become corrupted as we set
the restore point at the wrong place.

If we've explicitly requested a position (using -geometry) then we were
still triggering legacy full-screen request logic. This is very counter
intuitive as having a position that doesn't align with a monitor should
disqualify us for that.

It turns out that at least marco (and probably everything
metacity-derived) ends up ignoring the requested position and we go back
to triggering the legacy logic again.

Work around this by assuming that the window manager will adjust our
initial position and don't consider that in the workaround logic.

Update MonitorArrangement widget to match parameter settings after screen configuration change

If the options dialog was open when a screen configuration happened the
widget could get out of sync from the settings. A scenario when this
happened was:

 1) 3 monitors, fullscreen selected on the two right-most screens
 2) disconnect the left-most screen (the one not selected)

In this case, using GNOME, vncviewer would appear in fullscreen on the
right of the two remaining monitors, but the widget would show both
monitors selected. The reason was that the MonitorArragement index
doesn't work the same way as FLTK's screen index.

It's debatable how vncviewer should behave here, but the GUI should at
least match the actual setting.

There is no such thing as XDG_DESKTOP_NAMES.

The norm is to have error strings without punctiation, so avoid adding
one as it just confuses the translators.

Many window managers don't have proper logic to restrict the window size
to something sane, so we have to take care of that ourselves.

If this is done before the window is shown then it can accidentally
override the window manager's placement of the window. Reducing the size
should be sufficient to avoid trigger a full-screen request.

The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.

Tweak the workaround from 9023a2e so that it only triggers if there
actually is a problem to fix. This is important since changing levels
also has the side effect of raising the window to the top of the level.

This was designed as a general FLTK widget and we want to encourage
others to use it and improve it. So relicense these particular files in
a way that allows it to be used by anyone using FLTK.

As part of this we need to stop using other parts of TigerVNC as that
code is still covered by the GPL.

Fl_RGB_Image doesn't take ownership of the pixel data, so we have to
explicitly free this as well once we are done.

Bug introduced in fb561eb but still somehow passed manual testing.
Resulted in some stray reads off the end of the stack, which were
hopefully harmless.

These function are not guaranteed to succeed, and we've had reports that
they fail on ARM. So make sure we more properly check return values.

Try to be more consistent that related options should have a group box
around them.

This is what pretty much everyone else calls these kind of settings, so
let's change so users feel familiar.

Try to focus on the commonly used settings here in order to keep things
understandable. The uncommon settings will need to be specified as
command line arguments instead.

Clarify what this list is used for, and organize it so it is easier to
match to the options dialog.

We raised the requirement in cb3c78f but forgot to update the
documentation.

VENDOR_STRING is gone as is DEFAULT_LOG_VERBOSITY
site.h has been removed and is not needed.

Be consistent in "full screen" and "full-screen" use

Previously, there were a number of inconsistencies in the use of
"full-screen" and "full screen" in logs, documentation, and user
interfaces. The consensus seems to be that "full screen" is correct when
used as a noun while "full-screen" is correct when used as an
adjective. These inconsistencies have now been adjusted to follow
consensus.

Deduplicate vncviewer error messages

vncviewer previously had a the same localized error message duplicated
on a bunch of places. Pull these duplicates out into a single function.

It's difficult to support both old and new versions, so raise the
requirement to the oldest that is commonly used, which is CMake 3.10.2
on Ubuntu 18.04.

They don't really contribute to anything as the command line is fixed,
and it makes CMake 3.20+ upset since it cannot find that file and
instead thinks we meant maketarball.in (CMP0115).

This version of Ubuntu is no longer fully supported so let's stop caring
about builds there.

Can be helpful to see what encodings were actually used during a
connection, and how they performed.

macOS' built in VNC server unfortunately sends the entire monitor in a
single rect, so we need to be prepared to buffer a lot of data in case
the monitor has a large resolution.

Gives a bit more context where this error happened.

Single CPU machines are extremely rare now, so let's avoid the hassle of
multiple code paths.

If you close the reconnect dialog then we should assume that you want to
close things, not that you want to reconnect. Unfortunately FLTK returns
the first choice when closing the dialog, so that needs to be the
"Cancel" alternative.

The certificates might still be fine using the system trust store, or
the user can make an exception. So let's just log and continue on.

This got very common after 960c7d2 where we now always have a default
value for these settings.

Workaround FLTK bug that causes OptionsDialog to appear behind DesktopWindow

FLTK's fullscreen_x() function will always put the window on a high
level (NSStatusWindowLevel = 25), even if the window doesn't have focus.
This causes the OptionsDialog to end up behind the DesktopWindow when
the fullscreen function is called. Until we can rest assured that most
people building TigerVNC will use a fixed version of FLTK, we will need
this workaround.

Remove modal property from ServerDialog