fix(windows): refactor controller windows

Fixes #5004.

This cleans up the use of controller windows. A single window is now
given the responsibility of being the master controller, which receives
messages from Keyman32 and other components around UI activation, active
keyboard, etc.

The master controller is keyman.exe's `TApplication` window, which does
not get destroyed and recreated, unlike the main form window.

Any thread which has responsibility for Keyman UI (keyman.exe main
thread, keymanx64.exe main thread) is also registered as a controller
thread. A controller thread has special handling for interactions with
keyman32 around focus tracking.

Caveats:

* While keymanx64 does not have a visible window and thus probably does
  not need to be registered as a controller thread, it doesn't really
  hurt.
* Note that keymanx64 registers the 32-bit controller thread as well,
  which again is probably unnecessary as the 64-bit process cannot
  interact with the 32-bit thread.
* Keyman's main form still handles wm_keyman_control messages, as there
  are a number of other components which post to that window (e.g. text
  editor, com library visual keyboard interactions). Unlike the original
  problem trigger, the reference handle is not stored long-term and so
  there is unlikely to be a problem with main form window re-creation
  causing an issue in these contexts.

There are several TODO items in this which I will address in follow-ups,
to reduce the scope of these changes.

I hope to cherry-pick this to stable-14.0, but will run for a while in
15.0 before doing so.