Windows client: Running multiple instances per node

The Windows MSI installer only supports a single Icinga 2 installation per host.
The program directory is selectable during setup, but the data directory
(C:\ProgramData\icinga2) is not — it is always created in the same fixed
location. The Windows service is likewise always registered under the same name.
And because the package keeps the same product identity, running the installer a
second time upgrades, repairs, or relocates the existing installation rather than
adding a second one — even if a different program directory is chosen. So there is
currently no supported way to end up with two independently configurable agents
on one host.

We hit this in two scenarios:

Migration between Icinga environments. When moving hosts from one Icinga
environment to another (new master/CA, restructured zones, new platform), we want
to run the old and the new agent in parallel for a defined period: both report
into their respective environment, we compare check results and coverage, and
only then decommission the old one. Today the only way to switch is a hard
cutover — uninstall the old agent, install the new one — which means a monitoring
gap and no way to validate the new environment against the old one beforehand.

Multi-tenancy. Some hosts have to be monitored by two independent Icinga
environments at the same time, e.g. a system managed by an external service
provider that also has to report into our own monitoring. Each environment needs
its own endpoint/zone configuration, its own certificate and CA trust, its own
API listener, and its own log and state data. The environments must not share
configuration, certificates, or config-sync scope.

Both cases affect several hundred Windows hosts in our environment, so any
solution has to be deployable unattended and survive regular agent upgrades.

Solution I would like

Extend the MSI so that multiple independent Icinga 2 agent instances can be
installed and operated side by side on the same Windows host. Concretely:

• The installer accepts an instance identifier (e.g. an INSTANCENAME property),
  usable both in the GUI and for unattended installs via msiexec /qn.
• Each instance gets its own program directory (already selectable today) and
  its own data directory, which needs to become configurable per instance.
• Each instance registers its own Windows service under a distinct, predictable
  name (e.g. icinga2$<InstanceName>), so services can be started, stopped, and
  configured independently.
• Each instance has a fully separate configuration tree, certificate store, and
  log/state data. No shared state between instances.
• The Icinga Agent setup wizard can be run per instance and writes to that
  instance's directories only.
• Instances can be upgraded, repaired, and uninstalled individually, without
  affecting other instances on the same host. Uninstalling one instance must not
  remove shared or foreign data.

Alternatives I've considered

• Running additional instances manually. The daemon already accepts
  -D SysconfDir=... and -D LocalStateDir=..., so a second instance can be
  started with its own configuration and state directory. However, the MSI does
  not register a service for it: the service has to be created by hand
  (sc.exe) or wrapped with a tool such as NSSM, the directory skeleton and ACLs
  have to be created manually, and none of this survives an agent upgrade
  cleanly. Not something we can roll out and maintain across several hundred
  hosts.
• Copying/repackaging the MSI (separate ProductCode/UpgradeCode per
  instance). Works in principle, but means maintaining our own installer packages
  and redoing that work for every Icinga release.
• **Separate VM or container per monitoring environment..

Additional context

This is closely related to #5084, which requested multiple agent instances per
node in general. This request focuses specifically on first-class support in the
Windows MSI, so multi-instance setups become deployable and maintainable at scale
instead of relying on hand-built services.

Note that the migration use case is inherently temporary: the second instance
exists only for the duration of the parallel-run phase and is then uninstalled.
Clean per-instance install/uninstall is therefore the most important part of this
request.

Start by locating the Windows MSI packaging and service-registration entry points; the issue does not name specific files or tests. Compare the requested instance identifier, per-instance data directories, service registration, upgrade/repair, and uninstall behavior with the current msiexec and Icinga Agent setup-wizard flow. Done means independent instances can be deployed and removed without affecting one another.