fix(developer): debug.log created unexpectedly

fix(windows): Improve refresh reliablilty

fix(windows): Show full version with tag in Setup

fix(windows): OSK toolbar sync

fix(windows): exception handling list error

fix(windows): Improve refresh performance

fix(windows): Settings refresh management

chore(common): update copyright year in various locations

fix(windows): Proxy Configuration window size

fix(windows): keyboard help missing

fix(windows): prevent modifier key from navigating in download dialog

fix(windows): create task fails

Fixes #4110.

CEF will create a debug.log file in the current folder if it encounters
an error. Instead, it should be written to Keyman's diag folder. This
fix is for both Keyman Developer and Keyman for Windows.

Fixes #4001.

Stops navigation while holding Ctrl or Shift key taking over the whole
dialog rather than staying within the iframe.

Relates to #4116. This may not yet fix the issue; I don't have enough detail
to be sure of what the precise problem is. I have added one change to add a
username to the task definition, which may make a difference; and I will be
monitoring the more fine-grained exception reporting if that doesn't fix the
problem.

auto: increment beta version to 14.0.215

Fixes #4057.

Keyboard help link was missing from the help dialog
when instantiated from Keyman menu or OSK.

fix(windows): Warn if we reach maximum transient languages

auto: increment beta version to 14.0.214

fix(windows): sentrytool should fail build on exception and access violation when rewriting executables

auto: increment beta version to 14.0.213

This change has three fixes to improve the reliability of notifying
Keyman Engine of updates to settings or keyboard installs:

1. It removes the closure pattern of the refresh thread, because that
   was closing on a variable on a different thread (`RefreshHandle`) and
   that could cause races and/or exceptions in the case of early free.
   What's more, the closure was actually unnecessary as the variable was
   really only used by the refresh thread!

2. It moves responsibility for setting the refresh token to the calling
   thread so that the caller can depend on the token being the one that
   is actually sent, removing a race.

3. Most important, the refresh thread now flushes all messages in its
   queue, as there may be multiple messages relating to the window
   construction that need to be processed before the wm_keyman_refresh
   message can be handled. This greatly improves the chance of the
   notification actually being sent!

fix(windows): Online Update dialog layout was messy

fix(windows): exit button position on setup

fix(windows): uninstall language button z-index

Fixes #4041.

Show the version with tier and build flags in Setup so that it is clear
which version of Keyman will be installed, as the Keyman version can be
distinct from the setup.exe version.

Constructs the version tag from version+stability data in the
UpdateCheckResponse and uses a new MSI property called VersionWithTag
for Windows Installers. Older MSIs will still show a.b.c.d versions
instead of the tagged version if they are checked locally (as opposed to
online), because the new VersionWithTag property will not be present.

Another thought: we could also try refreshing every 125msec for 5
seconds after the first change is detected. It's a bit yuck perf-wise
but would probably be pretty transparent to the user.

In testing, this looks good. It means the changes appear as soon as
ready, without substantial delays or performance issues. Polling this
makes me feel a bit dirty, but I'll just take a shower and be okay.

As Keyman now monitors the Windows keyboard list from Control Panel, it
is no longer sufficient to refresh the toolbar only when a Keyman
keyboard is updated, as at that point Windows has not refreshed its own
language list in the registry. Instead, we need to monitor changes to
the relevant registry key and then refresh when those changes are
'complete'.

There is a problem: there does not appear to be a good way to monitor
for changes to Windows language settings. WM_SETTINGCHANGE is sent when
a language is added by the user in Settings, but the actual change
happens asynchronously, and we are not notified when the changes are
complete.

We also do not get notifications when languages are added via APIs.

Given the async nature of the language profile changes, this leads to
race conditions when we try to refresh the OSK toolbar. My preferred
solution currently is to monitor the relevant key in a separate thread,
and wait 1 second post-changes to actually do the refresh.

Fixes #4006.

This fixes the list error exception which was masking the actual cause
of #4006, which is already fixed by #4164.

Related issue #4119 is also fixed by #4164.

When a keyboard is installed, Keyman will now only refresh its internal
state on a given thread when that thread receives focus and/or input,
rather than immediately. This will dramatically reduce the chatter
caused by Keyman Engine when a keyboard is installed or settings are
changed.

Fixes #4011.
Fixes #4039.
Fixes #4121.

This change completes the immediate-change model for Keyman
Configuration, by refactoring the refresh of settings out of the render
phase and more appropriately splitting applying and refreshing. It adds
a new message flag for wm_keyman_refresh, KR_SETTINGS_CHANGED, which
uses a random token approach broadcast to all applications on the
desktop to ensure that the refresh is received and multiple
notifications for the same event can be appropriately coalesced.

Most of the files touched are stripping out the refresh flags from the
render phase.

There is one small bug resolved at the same time with the options
properties, which were not reset to default if they had been deleted
from the registry prior to a refresh (see utilkeymanoption.pas).

auto: increment beta version to 14.0.212