Unify installer scripts

### Checklist

- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate

### What is the idea?

Constructor's install and uninstall scripts currently exist in 3 versions:

* NSIS script, for the .exe installer
* A single .sh script, for the .sh installer
* A number of separate .sh scripts, for the .pkg installer. These are similar to the single .sh script, but not identical.

Most changes to the installation process must therefore be implemented 3 times.

Since the existing NSIS script will have to be completely rewritten anyway when Constructor moves off NSIS (#646), it’s worth considering whether this is an opportunity to unify all 3 scripts into a single codebase, which would reduce the amount of duplicate maintenance work in the future.

### What should happen?

There are two plausible options for which language a unified script could be written in:

Shell script:

* Would allow us to reuse the existing scripts from the .sh and .pkg formats, which are complete and battle-tested.

* The main issue is that Windows doesn't come with a Unix-like shell, so a shell executable would need to be bundled with the installer. This doesn't necessarily need to be Bash, since the existing script is already POSIX-compatible, and is verified as such using Shellcheck. A minimal, self-contained POSIX shell such as Dash is probably a better option.

* Windows would also require implementations of external Unix commands such as `rm` and `cp`. Something along the lines of BusyBox is probably the easiest way to provide these. Care would need to be taken to avoid using any versions of these commands which are already on the PATH of the target machine.

Python:

* Much easier to write secure and reliable code.
* Would require the installer to bundle a Python interpreter on all platforms. This is already present in installers which use conda-standalone, but not those that use micromamba.
* However, conda-standalone is already a requirement for most Windows installers, since micromamba doesn't support menuinst.
* @jaimergp also mentioned that a Python script is already used for some registry cleanup in the Windows uninstaller, because implementing it in NSIS was too difficult. This requires Python to be in the base environment even if it isn't used for anything else.
* PyInstaller works well on all platforms, and allows us to use a Python build installed by conda from a trusted channel.
* The install script could be run either:
* Via the existing conda-standalone executable (`conda.exe python`); or
* Via a new PyInstaller executable containing the current conda-standalone functionality plus anything else needed.
* PyInstaller's main downside is slow startup time because of the initial extraction process. But this could be improved either by:
* Using PyInstaller's `onedir` mode rather than `onefile`; or
* Doing everything within a single invocation of the executable, so it only has to be extracted once. For example, the script could execute conda commands via function calls if that is supported, or else by launching subprocesses via the Python executable in the PyInstaller temporary directory.

* MicroPython might be an option, but it appears to be not [fully supported on WIndows](https://github.com/micropython/micropython/blob/master/ports/windows/README.md). And most non-trivial code is not MicroPython-compatible out of the box, which would preclude using any third-party library.

Certain bootstrapping logic would still need to be written in a format supported directly by the OS – i.e. .sh on Linux and macOS, and .bat or .ps1 on Windows. But this would only be a small minority of the total code.

### Additional Context

Windows-specific issues:

* The registry can be accessed using the [`reg` command](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/reg), so no additional tools or libraries are necessarily required for that.
* Could shell or Python scripts be blocked by anti-malware systems?