ckan ksp fake/clone fixes

[DasSkelett]

@HebaruSan discovered some issues with my new two functions. This is how they behave now:

Both functions:
Write human-readable messages if there are too few arguments provided, no error messages due to crashes.

ckan ksp fake:

• Creates now all subdirs requested (see Add possibility to clone KSP installs and create dummy ones #2627 (comment)).
• Added --set-default flag to make the new instance the default afterwards.
• Also, if a user inputs a version number at least with major and minor, a selection dialog is raised to select a specific version (including build) known in the build map (else a message is raised to inform him to input a version with major and Minor at least).

This logic is now added as a new method of Versioning.KspVersion -> KspVersion RaiseVersionSelectionDialog(IUser).
Note that, despite the IUser being passed, only the cmdline User and the consoleUI User implement a RaiseSelectionDialog, so it won't work in the GUI without implementing a RaiseSelectionDialog.
Thanks @HebaruSan for the idea.

Fixes #2641
Fixes #2640
Fixes #2639
Fixes #2638
Fixes #2637

[DasSkelett]

Now the new FindKnownVersion() (also added in #2627) is not used anymore.
I'm thinking of deleting it and maybe moving the version selection 'algorithm' from FakeNewKSPInstall()there, what do you suggest?

Edit: Did it - see PR comment.

[HebaruSan]

Yes, I think moving the version selection logic makes sense so it could be shared among UIs. In the past this has been done by passing an IUser parameter. (Or perhaps your KSPManager already has an IUser object, probably should use that one if so.)

[HebaruSan]

It would be really nice to have a --set-default option to ckan ksp fake, to make the new fake instance the default instance. This would be handy for the validation scripts.

[DasSkelett]

Ooookay, I need some help understanding our Users/IUsers:
What are the virtual Display...() methods for?
Wouldn't it be easier to just override the Raise..() methods in each User class and thus derive them from the IUser interface instead of the NullUser class?

Edit: I see that the consoleUI does derive the User from the interface. Shouldn't this be the case for all Users (ConsoleUser and GUIUser)? At least that's what I think is the reason of the IUser interface, and the NullUser should be moved to in the Tests project and only be used there.

[HebaruSan]

Yeah, the structure is a bit messed up there, NullUser shouldn't really be inherited from, but I keep forgetting to go back and clean that up. If you want to fix it here, I would not complain. :)

[DasSkelett]

Okay, will do that, but on a new branch and PR, to keep it separated.

[politas]

Almost messed me up with that PR title. Bash ran the command when I tried to commit!