Add import downloads menu item to GUI

[HebaruSan]

Problem

Issues with downloading sometimes lead users to download files with a browser, but if it works, there's no way to make CKAN use the files. There should be, because they're the same files regardless of who downloads them.

Changes

This pull request adds a new "Import downloaded mods..." option to GUI's (slightly reorganized) File menu:

Clicking it brings up a file selection dialog where the user can select multiple ZIP files, starting in their profile's Downloads folder:

If the user accepts that popup, CKAN switches to the progress bar tab and displays messages about its progress in importing the files. At the end, if any of the mods are compatible and not yet installed, the user is asked whether to install them:

If the user clicks Yes, then they're taken to the install flow for those selected mods:

Finally, they're given another yes/no prompt asking whether to delete the original copies of the files that were successfully imported, now that they're in the cache. The idea is that some downloads are large and would waste space if kept in multiple copies. Apparently I did not capture a screenshot of this.

Code

ConsoleUI's download importing function is moved to be an instance method of ModuleInstaller, along with some mod formatting helper functions. This is then shared between ConsoleUI and GUI.

A new file MainImport.cs is added to GUI to contain all the GUI-specific importing logic. It mainly deals with showing the popup and calls the importing function of its ModuleInstaller.

Fixes #1788.

[techman83]

I've only had a cursory glance at the code, but how does CKAN figure out what zip relates to what mod version?

[HebaruSan]

It calculates the SHA1 sum of the file and looks it up in the registry (using a hash-to-mod index to speed it up). That's why there's a progress bar, in case we need to hash a very large file.

[techman83]

Oh cool. Found that now! Glad the Hashing stuff is getting used for other things now 😄 - should we be preferring SHA-256? Performance wise it isn't significantly worse than SHA-1, but cryptographically is far superior. We calculate the SHA-1 for use with Archive.org as our options were MD5, CRC32 or SHA-1.

[HebaruSan]

Yeah, the hashes are very useful to have around. 👍

As for SHA-256, we're not trying to protect sensitive data against cryptographic attack, we're just trying to identify some files. I didn't see an advantage on either side, so I just went with the one that's shorter. Luckily we aren't locked in if we need to change it in the future.