Don't report an unknown error if it is known

[DasSkelett]

Problem

When there's an exception thrown during the installation of mods, we catch the usual ones and log an explanation message on the WaitTabPage.
However in PostInstallMods() which is called when the background worker completes InstallMods(), the message An unknown error occurred, please try again! is written to the "log".
This message is actually not true most of the time, because e.g. download errors or inconsistency problems are all catched and a nice explaining error message has already been printed out.

Changes

Now PostInstallMods() distinguishes catched and uncatched errors (the second one will result in RunWorkerCompletedEventArgs.Error being set).
It keeps the old message for uncatched errors, but displays a new one for known ones:

If the above message indicates a download error, please try again. Otherwise, please open a 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

(Suggestions to change this message are welcome)

This way we don't contradict ourselves, and also encourage the users to report metadata/client problems.

[DasSkelett]

Easy way to test this PR: Block github.com and archive.org in your hosts file (works on Windows too).

[HebaruSan]

Took me a while to figure out exactly when we fail without e.Error set; it's in all the catch blocks of InstallMods that print an error and return. But this makes sense!

[DasSkelett]

Took me a while to figure out exactly when we fail without e.Error set; it's in all the catch blocks of InstallMods that print an error and return. But this makes sense!

Yes indeed. e.Error is set by the runtime when an exception inside the worker hasn't been catched.
I was thinking about refactoring the InstallMods to not catch the exceptions and let PostInstallMods handle it, but I didn't want to mess with it and potentially introduce bugs just for this little output change.

[HebaruSan]

That would make more sense, arguably more in line with how BackgroundWorker is designed.