LSP4J is blocking other updates

[petervdonovan]

eclipse/xtext-core#829 mentions a preference to update our LSP4J version from 0.10.0 to 0.12.0.

A version bump has already been attempted for LSP4J as part of eclipse/xtext-core#542, and it caused a NoClassDefFoundError to be thrown at runtime from the VS Code extension.

@a-sr explained to me that

there is no new release of Xtext alongside the Eclipse release, which means they are not yet compatible to the new lsp4j API (related Xtext issue)

If I understand correctly, this means we cannot update LSP4J unless/until we abandon Xtext.

Consequently, I partially reversed eclipse/xtext-core#542. However, we cannot leave the situation as it is now because what I had intended to be a temporary workaround has resulted in the Oomph setup tracking the 2021-09 Eclipse release while the target platform tracks the 2021-06 release. If I understand, this inconsistency results in our having to make changes like fb447a2 in eclipse/xtext-core#843 in order to silence errors in Eclipse -- but fb447a2 breaks the language server.

We could completely go back to 2021-06. I consider this a reasonable last resort to get both the Eclipse setup and the language server to work. However, if @a-sr or anyone else knows of another way that lets us only hold back the LSP4J version without setting all Eclipse dependencies back to 2021-06, that might be preferable.

[lhstrh]

Would it make sense to try v2.26.0.M2 of Xtext? There they already use 0.12.0, see: https://github.com/eclipse/xtext-core/blob/1ff1da2dfdc7b0e1db2e9087acfca8e42819dcc0/org.eclipse.xtext.ide/META-INF/MANIFEST.MF

[lhstrh]

I could give this is shot in #829