Reverts some of the version 2.0 project functionality, as there are a
number of challenges around populating files for folders that don't have
project definitions, particularly if user attempts to load a folder that
is not a project folder after all but happens, e.g. to have a source
folder in it.

Fixes #10031.

Closes Debian bug
[#1057134](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057134).

(cherry picked from commit f50eccc)

This is a bit of an omnibus commit, apologies for that. This commit
moves Keyman Developer to a proper multi-process model, where editing
files from multiple projects is handled much more cleanly, with each
project loaded in a separate process.

Files that are edited outside of a project structure are loaded into a
'temporary project' in a single process, which provides a pathway for
existing users who may have legacy files outside the normal Keyman
Developer project model.

There are several components to this:

1. Inter-process communication (Multiprocess, CopyDataHelper units and
   multiprocess test project). These modules establish a method of
   enumerating running Keyman Developer instances (with EnumWindow),
   recording relevant metadata for each instance (by thread id) in the
   registry (registry used because it manages contention without
   additional effort from us), and communicating between processes with
   WM_COPYDATA.
2. Command-line parsing (TikeCommandLine). Determines project ownership
   (ProjectOwningFile) for each filename passed on the command-line, and
   passes these over to existing instances of Keyman Developer that have
   that project loaded, or starts new instances as needed.
3. Temporary project management. Mostly in ProjectUI.

Also, moved GlobalProjectStateWnd management out of ProjectFile.pas and
into Project.pas, alongside other global project variables.

A follow-up will add functionality to determine if a file opened within
the Keyman Developer UI should open in the same instance or in a
separate instance (see TfrmKeymanDeveloper.OpenFileInProject). This will
use the same methodology as TikeCommandLine does now, so may involve
further refactoring.

This commit establishes the idea of 'keyman.kpj' as a future default
filename for Keyman Developer projects, but does not enable it, in
ProjectOwningFile. It is planned to introduce this fixed filename in
version 18.0 (see #10113).

…al-paths

chore(developer): require project file to exist 🦕

chore(linux): Add support for loong64 architecture 🍒

Fixes #10111.

(cherry picked from commit e4385e2)

fix(web): Don't throw errors after detach

auto: increment master version to 17.0.222

This adds a `coverage` parameter to `web/build.sh` that will create
a coverage report in HTML format in `web/build/coverage/index.html`.

…tils-npm-module

fix(common): publish @keymanapp/developer-utils as npm module

auto: increment master version to 17.0.223

Refactor the file-opening code so it can be used by Keyman Developer UI
as well as command-line, and then add support for opening files in
per-project instances from File|Open and friends.

Also moves the initialization code out of tike.dpr into
Keyman.Developer.System.Main.pas, which makes it easier to maintain and
read.

Co-authored-by: Marc Durdin <marc@durdin.net>

chore(web): Add option to create test coverage report file

auto: increment master version to 17.0.224

Fixes #10003.

Multiple small fixes required here:
* Add .kpj as an editable file type
* Ensure that when OpenFile returns nil (which it always will for a
  .kpj), that we don't crash
* Ensure that projects open in a new process rather than replacing the
  current project session

Adds a TODO for New Project -- this should be opened in a new process if
we already have a project open in the current process. Will push this
into a separate PR.

…gelog

chore(linux): Update debian changelog 🍒

Fixes #10099.

…ug-build

fix(windows): debug includes libcmtd vs libcmt.dll