Dynamically Loading Libraries

[radeusgd]

Pull Request Description

Refactors the modules and packages systems so that they can be loaded dynamically.

Related to #1781, but does not implement its full spec (edition resolution is left for a separate PR).

It also implements an interface allowing to use the standard SLF4J logging utils from within the runtime; this interface is connected to the TruffleLogger which then passes the logs to our logging service.

Important Notes

• I removed the concept of 'shadowed packages' as it does not seem to be well-defined in the context of the new edition-based resolution system, but I'm willing to discuss if this should be handled differently. Main point is - we do not know what packages are available (well, we could look through what is defined in the edition + what is available on all paths in the local search path) so it is unclear if something is shadowing something else.
  • The only reasonable situation seems to report that the current project is shadowing some library that is defined within the edition - this could indeed be checked.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the Scala, Java, and Rust style guides.
• All documentation and configuration conforms to the markdown and YAML style guides.
• All code has been tested where possible.

[radeusgd]

• I removed the concept of 'shadowed packages' as it does not seem to be well-defined in the context of the new edition-based resolution system, but I'm willing to discuss if this should be handled differently. Main point is - we do not know what packages are available (well, we could look through what is defined in the edition + what is available on all paths in the local search path) so it is unclear if something is shadowing something else.

  • The only reasonable situation seems to report that the current project is shadowing some library that is defined within the edition - this could indeed be checked.

cc: @kustosz @iamrecursion any thoughts about this?

[kustosz]

Code looks good, but there's an architectural problem with this solution. You have the context (which is "deep compiler, here be dragons") talking directly to the language server (which is "what compiler, me just want code go brrr"). This skips a layer of our runtime server, responsible for translating between the compiler and the LS. This will probably result in very client-specific logic being added to the context over time. All of this logic should be mediated by our pre-existing handlers system.

[iamrecursion]

Just some notes on documentation. I'd like to echo what Marcin has said in his review.

[kustosz]

LGTM

[4e6]

are you just inverted interactive mode twice, or I'm missing something?

[radeusgd]

Oh that is a mistake, it was supposed to be if(isTextMode)! Thanks!