Support different kotlin/kotlinc install directory setups in backup classpath resolver

[themkat]

Found out about this issue after investigating the issue in:
fwcd/vscode-kotlin#101

Usually I just use Maven or Gradle, so I almost never need to have a kotlinc/kotlin install available for the language server. The current language server expects a structure like this: libexec/bin/kotlinc, but that is not always the case.

Example on my machine. kotlinc in path resolves to /opt/homebrew/Cellar/kotlin/xxx/bin/kotlinc. stdlib lies in /opt/homebrew/Cellar/kotlin/xxx/libexec/lib/. Because kotlinc is resolved to that place, resolving lib like the code does now (before the PR) won't work as there is no lib-directory in the parent directory. We will have to navigate to libexec, and then lib.

Another example is sdkman installs. In that install, the current implementation would work as it is still has a lib-directory in the parent. kotlinc-location .sdkman/candidates/kotlin/1.7.10/bin/kotlinc. The lib-directory is there with the bin-directory in the parent.

Unsure if it will solve the snap issue (discussed in the issue linked to above). snap requires insane amounts of permissions, so wasn't able to get it working inside a docker container. Reminds me of why I avoided it when I still used Debian-based systems 😆 If any of you use snap, could you post the location of kotlinc and stdlib jar file? If you want to send in your own PR with a fix for it later, that is probably also awesome for the people using snap 🙂

I kept the takeIf-expression, even though we have already checked it for one of the possible options. The reason for not putting it into the let, is because I think it was way more readable this way.

[fwcd]

Looks good! The entire resolver is unfortunately a bit hacky, resolving the library correctly in every environment is pretty hard, given how much packaging of the Kotlin compiler differs across platforms, but adding a fallback for this seems reasonable.