feat(windows): Online Update - Scheduled Services - Stage 2

Keyman for Windows online updates - **Scheduled Services** - Stage1

## Table of Contents
1. [Introduction](#introduction)
2. [Detail](#detail)

# Introduction

The ideal end goal of the online updated work is to automate the updated process with zero user interaction.
There are many obstacles to achieving this some of which are out of Keyman control.
However, we can make steps towards this goal.
This issue is for stage 2 adding a Scheduled Service will:
1. Reduce the need for requesting elevated permissions from the user.
2. Revisit the change made in #13153
3. Allow the check for updates to be done on a guaranteed interval independent of Keyman running.
- Elevation - installing keyboards and Keyman both require elevation - will be solved by the scheduled task.
- Files in use - updating Keyman files often requires a restart (we can’t avoid).
- Keyman32.dll will be locked with SetWindowsHookEx hooks – with no clean way of releasing it from memory in all processes
- kmtip.dll can be locked as it is selected as an input method

# Detail

See the [original design notes](https://docs.google.com/document/d/1b2rybSf2188Vbgx8tystQn6351bZfROYkXzPYEAi-ro/edit#)

See Stage 1: #10038 with changes to the Keyman Configuration

# Functional Spec
In this Stage, two scheduled tasks shall be added one to check for updates, the second to start the install process as admin avoiding the need to ask the user for `Elevated` permissions.

1. Auto Update scheduled task should always be installed, but do nothing if auto updates are off
1. Check for updates should be triggered by user but run as an elevated scheduled task
2. Note we must be aware of user vs machine preferences!
1. e.g. keyboard is installed for machine – but language preferences are per-user
2. Keyman options are nearly all per-user (except base keyboard I think)
3. There are two scheduled tasks:
1. **Check for updates** – checks online for an update, and downloads it to a cache - replaces equiv functionality in kmshell
1. Keyman Configuration can trigger the same schedule task download via check for `updates now`.
2. Scheduled task is the admin user so that it can store the cache data in folder that the installer running as admin can also access with out having to prompt the user for elevated access.
3. Scheduled task downloads metadata + binaries and puts them in a cache folder (e.g. ProgramData\Keyman\Updates)
4. Once it has finished, it signals Keyman Configuration (e.g. SendMessage) OR can just check for the cache download on start up. Keyman.exe could also poll the to see if the download is available hourly.
5. Write a flag to register for update, and cache file location
6. Keyman Configuration read the metadata file. (Don't forget about file lock/share conflicts on either side here!)
2. **Apply updates** – takes updates that are in the cache, and installs them
1. If manually started from the Configuration menu, call the scheduled task so the install can still run with elevated permissions, shutdown Keyman, Keyman Config, to minimize file locks – but we understand that a reboot may still be required - again we can’t do anything about this.
2. the scheduled task sets the `background Update State` Flag `usInstalling`
3. the scheduled task first installs keyboard updates
5. the scheduled task next installs app updates with the bootstrap executable
6. immediately after triggering the Windows Installer, the scheduled task shuts down – to avoid locking files.
7. the bootstrap installer, at the end of install, sets the `buState` Flag to `usWaitingPostInstall`
5. Keyman itself (and Keyman Configuration) must check on startup for the state flag for `usInstalling`, and immediately exit if so to avoid file lock issues)
1. If the state flag is `usInstalling`, present UX to the user to allow them to clear the flag, in the case of a failed install:
1. For the starting Keyman from Start Menu, or starting Keyman Configuration
6. To investigate: what happens when a TIP is selected – is it possible for the TIP to say "NO DON'T ACTIVATE!" when it is selected, or does it still end up locked in memory? (This could bring us unstuck even in the login screen where TIPs are available even if not working)

Extra Thoughts
*Wild idea for file lock mitigation for TIP from the installer side:*
when the installer starts, iterate through all user desktops and set the language to something other than a Keyman-TIP language.

#TODO: Clean UP

# Issues / PRs
Epic PR is: #9330

- [ ] https://github.com/keymanapp/keyman/pull/10032
- [ ] Update Keyman Configuration as per functional spec
- [ ]

# Related PRs
- https://github.com/keymanapp/keyman/issues/7749
- https://github.com/keymanapp/keyman/issues/4544