Export dedicated language parametric client instance

[DavyLandman]

Currently all DSLs are connected to the Language Parametric LSP server. This multiplexer works really nice during development.

When deploying a DSL in it's own VS Code extension, there are a few small problems:

• all DSLs are running in the same JVM, one out of memory will crash them all, and no current way to recover from that
• the language inside VS Code will always show as Parametric Rascal LSP
• If a DSL extension wants to add specific functionality, it's opportunities are limited.

My proposal:

1. also export a function that builds a new LanguageClient (that internally constructs the right jvm for the right jar)
2. DSL authors can then write their own extension (we could build a small scaffolding script for it)
3. DSL extension gets a new dedicated LanguageClient and sends one (or more) registerLanguage call to it.

[DavyLandman]

We might have to extract the file system registration into a seperate jvm process.

[jurgenvinju]

We might have to extract the file system registration into a separate jvm process.

that was the plan anyway, so that's ok.

About the other feature, it sounds like a good plan. I think we need to add more tests before doing this. This is yet another way to use the parametrized LSP and this way will even be tested less than our current implementation since it is only truly useful after deployment. So I propose we invest in testing the parametric LSP with feature-tests before we start adding this new mode of using it, and also think of a way to test this new way of connecting.

BTW, when the Rascal compiler comes into the picture, some of this will have to be revisited.