Change how rascal-lsp is release on maven

[DavyLandman]

Is your feature request related to a problem? Please describe. Currently we release rascal-lsp on usethesource's maven repository. Just so that people can have a dependency on the util::LanguageServer. But this jar contains a lot of other stuff: the whole rascal-lsp implementation. But more importantly, it imports a dependency on a specific version of rascal-core and typepal. They are not needed for util::LanguageServer and can cause subtle issues.

Describe the solution you'd like

Either we figure out a way to mark those dependencies as not transitive, or move the util::LanguageServer onto a seperate project, and move the implementation of the server to rascal-lsp-server project, and let that contain all the internals.

(related to #222 )

[jurgenvinju]

I see the point, but splitting packages is work and it incurs maintenance overhead. So is there actually a problem, or is this a proposal for perfective maintenance? both are fine, but the difference helps in scheduling the work.

the implementation of the P-LSP and the R-LSPs are very tightly coupled, not directly but semantically. They follow the same design and technical solutions. I'm hesitant to split this code and allow them to independently evolve. I'd rather have them stick together, and even merge more closely (i.e. such that the R-LSP is implement in the P-LSP).

[DavyLandman]

it causes problems if you depend on lib://typepal in your RASCAL.MF but don't explicitly add a typepal dependency in your pom.xml. Since then typepal flows from the rascal-lsp dependency, which could be okay for execution, but your IDE (and your maven build step) will fail, as the tpls are not compatible, since we use a old version of typepal. This is not helped by the fact that the jar is shaded (#222)

For making deployments, we have to explicitly state in our maven dependency that we don't want rascal-core or typepal from the rascal-lsp project, but in the end we still get a lot of other dependencies along.