Support multiple KSP installs.

[pjf]

(Text mostly taken from @Wizarth in #23)

It's a common use case for modders to have multiple installations/copies of KSP.
I suggest a per-user index of installs. This is enough data to point one instance of
CKAN to different installs of KSP, each with it's own per-install data store.

We can safely assume any install folder will be writable by CKAN (or else how would we
install mods).

ckan list-installs
ckan add-install name path/to/install
ckan modify-install name changed/path/to/install
ckan remove-install name

This then allows users to specify which install they want to operate against. If one is not
specified, assume special case default.

ckan --ksp=0.24_IQ list

As per #28, if no installs defined, CKAN should attempt to automatically detect default. (E.G. Steam).
If not possible to detect, user should be prompted to define default install.

Install data should be stored in the Windows/Mono registry, since we can't access (or even create) the CKAN registry until we know which install we're dealing with.

Currently being worked upon by @Wizarth, unless he claims otherwise. ;)

[AlexanderDzhoganov]

This has been implemented for both cmdline and GUI in #125, closing issue.

[pjf]

For what it's worth, the coolest way to close issues is to simply have "closes #29" in a git commit. When that merges to master, it will close the issue automatically. It's super cool, because it means that when a branch it merged it closes all the issues it solves, and when a branch is pending merge you can still see where the commits that that are needed for issue resolution. It's one of my favourite workflows ever. :)

[AlexanderDzhoganov]

Makes sense, I will do this from now on :)