Support modulepath imports

[DrWursterich]

Closes #91

I saw #93 and #120 and adopted both approaches, the SettingsManager and the EvaluatorSettings. I decided to priorize the SettingsManager's modulepath when resolving since that could offer a way to "override" a projects modulepath locally.

I also added completion for import, amends ect.

---

Addressing the feedback on #93

The setting should be part of configuration (see SettingsManager). On the client side, this should be configured differently depending on the editor (in VSCode, it should be defined in the extension's package.json)

Should be solved, right? We do use the SettingsManager here, and everything else would have to be done in pkl-vscode. While looking into the now-botched #93 I found that @sitepark-schaeper has a version of that, but I don't know if that works or not. It was trivial for neovim.

When resolving relative paths, we should determine whether that file exists within the modulepath or not. If so, relative paths should be resolved according to the modulepath. For example, import "/foo/bar.pkl" should look within modulepath.

This is covered specifically by the test cases resolve relative field in modulepath and resolve modulepath field in modulepath.

Resolving a modulepath resource should look at each jar/directory (as determined by the order of jars/dirs) and return the first file that exists. This follows the same rules as classpath resources in Java.

The implementation does exactly that. It iterates through all modulepath entries (first from the SettingsManager, then from the EvaluatorSettings) and the first file that exists is used.
Soley jar entries have not been tested, as I am unsure how to do so. If you need me to do that as well please help me setup a test to implement against.

---

Please let me know if there’s anything else I can improve or clarify to help move this feature forward. I’m happy to iterate further.