Give access to custom ClientCapabilities

[aeschli]

ClientCapabilities currently only support the standardized set of capabilities.
Protocol extensions (such as https://github.com/Microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.workspaceFolders.proposed.md) add additional capabilities, to existing sub-capabilities (workspace, textDocument) but potentially actually to any sub-capabilities.

-> Add an API to ClientCapabilities to get any capability by key.

[mickaelistria]

Using protocol extensions really makes everything more complex in general.
I think it would be simpler to integrate the protocol extensions as standard capabilities in LSP4E, especially if you're using SNAPSHOTs. This would allow to more easily validate that the proposal in the protocol is also usable in the LSP4J world.
I'm planning to provide a PR to have the proposal about multi-root directly in.

[mickaelistria]

@aeschli It would be nice if you could submit the WorkspaceFoldersProposedService to LSP4J directly and consume it in JDT-LS. That would allow LSP4E, Che and any other language server building on top of LSP4J to start trying it with the same API.

[mickaelistria]

See #132 and #133 for contributions about workspaceFolders.

[gorkem]

@mickaelistria Do you still need to move WorkspaceFoldersProposedService after #133? I want to revert to using LSP4J proper on jdt.ls just wanted to check with you if you captured all that is needed.

[mickaelistria]

LSP4J has implemented everything necessary to support multiple root according to the proposal, without extension required on server and client side. It works perfectly in Eclipse LSP4E. Nothing else is needed for it.

[jonahgraham]

It works perfectly in Eclipse LSP4E. Nothing else is needed for it.

Based on this I am closing the issue. Please reopen with additional comments if there is still stuff to be done here.