Distribute SCMU as a self-contained application instead of an installer

[bording]

• Requires Distribute the PowerShell module both via the SCMU installer and via the PowerShell Gallery #3286
• Requires Add a warning to the PowerShell module distributed via the SCMU installer #3287
• Requires Remove the PowerShell module from the SCMU installer #3288

Once all of the prerequisites have been met, we can remove the installer. When the self-contained application runs, it should check if there is an installer version of SCMU still in the environment it is running in. If there is, it should let the user know that they should uninstall that version.

The PowerShell scripts as well as SCMU should have version checks in place to reduce the likelihood of version mismatch errors.

This removes the installer process, but is not a breaking change as no functionality has been removed from the user. This can be done in a minor version.

Rationale

ServiceControl currently uses a Windows installer to install the SCMU application. This installer is specific to Windows and will not be portable to any other operating system. Once the installation is complete, SCMU can be run as a WPF application. The benefits to installing SCMU instead of deploying it as a simple exe are few.

SCMU is a WPF application that allows for basic management of ServiceControl instances. Customers currently have to upgrade SCMU, then upgrade each instance of ServiceControl.

Instead, the SCMU WPF application can be converted into a self-contained application that does not require installation.

A complexity is that currently the SCMU Installer is used to distribute the PowerShell module used for managing ServiceControl instances. A new way of distributing and updating the PowerShell module needs to be found. Changing the way the PowerShell scripts are deployed is a breaking change for how users consume the modules. This applies to changing the PowerShell modules to be command line arguments too.

• A self-contained application could be distributed and upgraded via package managers like winget, chocolatey, or scoop
• Distributing a separate PowerShell module will allow customers that only use scripts to avoid installing unnecessary software

Benefits of having SCMU be an installed application

• It is very hard for a user to use an incorrect version of ServiceControl to what version was intended
• A shortcut and start menu icon adds a convenience factor to users

Benefits of having SCMU be a self-contained application

• No need to build an installer (The entire advanced installer project can go away)
• One less windows-specific dependency in ServiceControl
• The concept of an installer does not translate to other operating systems in a meaningful way
• Easier upgrade and downgrade path for users

We don't need to have an installer for ServiceControl. Instead, we can make SCMU itself be the distributable artifact.

I have created a spike to demonstrate this.

The key changes in the spike that make this feasible:

1. SCMU becomes a self-contained net6.0 application
2. All of the zip files become embedded resources

This lets the SCMU exe be run directly without any system dependencies, and it can install/manage any instances.

[DavidBoike]

Implemented in #3756 and will be shipped with ServiceControl 5.0.