fix(windows): set basekeyboard as current user not the admin user on a elevated process.

[rc-swag]

Fixes: #15152

This was quicker fix then I thought the more through issue 15154 still remains to catch discover all the cases the non-admin user configuration changes that may been attempting.

Build-bot: release:windows

User Testing

1. Login into Windows with and account that is a "standard" user and does not have "Administrator" rights.
2. Install the Keyman from this PR
3. Open Keyman Configuration -> Options
4. Click Base Keyboard you will need to enter the login details for a Admin user. Change the Base Keyboard
5. Confirm the Keyboard changes for the current user and not the Admin user used for the elevated processs

[keymanapp-test-bot]

User Test Results

Test specification and instructions

ERROR: user tests have not yet been defined

Test Artifacts

• Windows
  • Keyman for Windows
  • FirstVoices Keyboards for Windows
  • FirstVoices Keyboards for Windows (old PRs)
  • Keyman for Windows (old PRs)
  • Text Editor (ARM64)
  • Text Editor (x64)
  • Text Editor (x86)

[mcdurdin]

I don't think this is correct. The base keyboard dialog needs to run elevated -- because when you change the base keyboard, Keyman needs to mcompile each of the installed keyboards against the new base keyboard:

keyman/windows/src/engine/kmcomapi/com/options/keymanoptions.pas

Lines 133 to 135 in 1536a5f

	if FOldBaseLayout <> Get_Items('koBaseLayout').Value then
	for I := 0 to Context.Keyboards.Count - 1 do // I4169
	(Context.Keyboards.Items[I] as IIntKeymanKeyboardInstalled).UpdateBaseLayout;

The problem here is that the base layout setting is saved against the Admin user, but needs to be saved against the current user. This probably is best solved by splitting the admin component -- mcompiling -- out of the TKeymanOptions.Apply function, and running it as a separate step from the Base Keyboard dialog. Then the Base Keyboard dialog does not show elevated, but just elevates when OK is clicked, if it detects that new mcompiles need to be run, and does that as a kmshell -mcompile <basekeylayoutid> call? (implementation calls: TKeymanKeyboardInstalled.UpdateBaseLayout for each installed keyboard).

TKPRecompileMnemonicKeyboard then needs a parameter for the base layout, rather than reading it from the context options:

keyman/windows/src/engine/kmcomapi/processes/keyboard/kprecompilemnemonickeyboard.pas

Lines 87 to 88 in 9779792

	with Context as TKeymanContext do
	BaseKeyboardID := (Options as IKeymanOptions).Items['koBaseLayout'].Value;

So some plumbing required, sadly.