Finish separation of LSP interface from LSP implementation; move util::LanguageServer to standard library in rascal project

[jurgenvinju]

We have prepared for injecting the LSP implementation in rascal-lsp into a Rascal run-time:

• the key Java interface method IDEServices.registerLanguage is part of the IDEServices interface which is provided by the rascal project.
• IDEServices implementations are injected through the JavaBridge via either the evaluator's configuration or the compiled-code configuration.
  • in the standard library the registerLanguage method throws a "not implemented" exception
  • in the terminal that connects to the LSP, the method sends a JSON RPC call to the parametrized LSP JVM to hook up a language
  • in the parametrized LSP JVM the method hooks up directly to the LSP implementation.
  • etc. there could be Eclipse implementations, Emacs, you name it. It is all handled through dependency injection via the IDEServices java interface.
• The module util::LanguageServer now depends on the RascalInterface class for implementing registerLanguage, but that one is easily migrated to the IDEServices API as well:

public class RascalInterface {
   private final IDEServices services;

   public RascalInterface(IDEServices services) {
       this.services = services;
   }

   public void registerLanguage(IConstructor lang) {
       services.registerLanguage(lang);
   }

   public void unregisterLanguage(IConstructor lang) {
       services.unregisterLanguage(lang);
   }

   public ISourceLocation resolveProjectLocation(ISourceLocation project) {
       return services.resolveProjectLocation(project);
   }

   public IList computeFocusList(IConstructor input, IInteger line, IInteger column) {
       return TreeSearch.computeFocusList((ITree) input, line.intValue(), column.intValue());
   }
}

By moving util::LanguageServer finally to the standard library we cut the unnecessary links between interface and implementation of language services, with these benefits:

• Rascal-based LSP servers do not need a dependency on rascal-lsp anymore, only on rascal
• Development and testing of Rascal-based LSP servers can happen without and outside the VScode environment if so required (unit testing!)
• util::LanguageServer becomes a core part of the documentation and typical lore of the Rascal community, rather than an extension.

Pitfalls:

• More future co-evolution between rascal-lsp implementation and the rascal project; things can no longer be handled internally in rascal-lsp. The LanguageServer module becomes a contract between the standard library and rascal-lsp, as it is already a contract between the rascal-lsp library and the differerent DSLs.

I believe something to do after the big upcoming release. It should have zero effect on user code, but people will want to clean up their dependencies after this change is released. Sounds good for a separate release notes etc.