Fix tracking of paths with trailing spaces on Windows

[HebaruSan]

Problem

If you install MrScienceMeistersNuclearWarfare (latest version is for KSP 1.0.5) on Windows and then try to uninstall it, you get this error:

About to remove:

 * MrScienceMeister's Nuclear Warfare 0.5.1
Could not find a part of the path 'D:\SteamLibrary\SteamApps\common\Kerbal Space Program\GameData\NuclearWarfare\Parts\freeFallNukeBrake'.
Error during installation!
If the above message indicates a download error, please try again. Otherwise, please open an issue for us to investigate.
If you suspect a metadata problem: https://github.com/KSP-CKAN/NetKAN/issues/new/choose
If you suspect a bug in the client: https://github.com/KSP-CKAN/CKAN/issues/new/choose

Cause

The path can't be found because the installed_files entry in registry.json doesn't match the path on disk.

ModuleInstaller assumes that Directory.CreateDirectory and File.Create will either create the paths they're given or fail. Astoudingly, this assumption is false on Windows, a purportedly real professional operating system that is sold to users across the world! Instead, both of these functions silently trim trailing spaces from paths. This code:

Directory.CreateDirectory("test path      ");

... creates a directory called test path with no trailing spaces. This happens silently; there's no exception or other explicit indication that something unexpected has happened. If the application code needs to know the path, it has to know about this potential problem (despite it not being particularly clearly documented) and implement a workaround for it.

Two directories in MrScienceMeistersNuclearWarfare end with trailing spaces. So when we uninstall this module, we try to remove the path with the trailing space, but Windows doesn't find it because it's not there, having been replaced by a different path during installation. 🤦

Changes

• Now ModuleInstaller.CopyZipEntry returns the path it created
  • For directories, the TxFileManager.CreateDirectory function we use has no return value, but Path.GetDirectoryName apparently performs the trimming logic, so we use Path.GetDirectoryName(Path.Combine(fullPath, "DUMMY"))
  • For files, File.Create returns a FileStream object with a Name property that has it
• Now ModuleInstaller.InstallModule collects the created paths from CopyZipEntry and returns them instead of simply assuming that every InstallableFile.destination will be created as requested

This will ensure that the entries in registry.json always match the real paths on disk, so uninstallation will no longer be tripped up by this Windows quirk.

Fixes #3585.

[DasSkelett]

Oh Windows, always good for surprises.
Didn't test on Windows, but it doesn't break anything on Linux and the code looks sensible.