[Installer] Add an Inno Setup generator next to NSIS.

COCKATRICE_WIN_INSTALLER chooses which tool writes the Windows installer.
NSIS stays the default, so nothing on the existing path changes; InnoSetup
selects CPack's own INNOSETUP generator (CMake >= 3.27) and builds from the
same install() rules. Both can be built from one tree and the resulting
installers compared on an upgrade from 3.1.x.

What the Inno path does differently:

- Installs over the previous version instead of running the old uninstaller
  first, which is what the backup/restore pair in the NSIS template exists
  to survive.
- Closes and restarts a running application through Windows Restart Manager
  (CloseApplications/RestartApplications) instead of the two PowerShell
  process guards the template needed.
- Removes stale runtime with one [InstallDelete] of *.dll and Plugins,
  instead of RetryDllPurge and its diagnostics.
- Writes a log on every run through SetupLogging, instead of CockLog.
- Resolves the install directory from the legacy NSIS registration, and
  deletes that registration after a successful install so the old
  uninstaller (whose blanket directory removal caused the 3.1.x data loss)
  cannot be run after the upgrade.
- Keeps the portable mode the client detects, the C++ runtime bootstrap and
  the /PORTABLE switch.

The in-app updater still passes the NSIS switches (/R, /PID=); the installer
logs them so the first Windows run settles whether Inno Setup accepts them or
the switch-over needs a client version gate.

The installer content check in .ci/compile.sh learns to strip Inno Setup's
{app} prefix from the paths 7-Zip lists, so the required-runtime comparison
works for either archive format.

cmake/InnoSetup.install.iss

@@ -0,0 +1,23 @@
+; Sections added to the setup script CPack's Inno Setup generator writes.
+;
+; Included through CPACK_INNOSETUP_EXTRA_SCRIPTS, which prepends this file to the
+; generated script. Only sections the generator never emits may appear here: it writes
+; [Files], [Dirs], [Icons], [Run] and [Registry] from the install() rules, and a second
+; section of one of those is a compile error. Behaviour belongs in InnoSetup.code.iss.
+
+[InstallDelete]
+; The previous version's runtime, whatever it was called. Replacing a DLL in place is not
+; enough: a module the payload no longer carries (Qt6Multimedia.dll while it was still
+; shared, Qt6QuickWidgets.dll) would survive the install and then be loaded next to the new
+; executable, which is the "procedure entry point ... could not be located" failure after
+; an update. Removing every DLL and letting the payload put its own back is what the NSIS
+; RetryDllPurge did with 250 lines of retry and diagnostics; with CloseApplications on,
+; Restart Manager has already released the handles, so one pass is enough.
+Type: files; Name: "{app}\*.dll"
+; Plugins are loaded by name from this directory, so a stale one is just as fatal and is
+; not covered by the payload's own file list.
+Type: filesandordirs; Name: "{app}\Plugins"
+; The NSIS uninstaller. Its Add/Remove Programs registration is deleted after a successful
+; install (RemoveLegacyNSISRegistration in InnoSetup.code.iss); the binary itself has no
+; business staying next to the new one.
+Type: files; Name: "{app}\Uninstall.exe"