WIP: support for lsp next (lsp-register-client)

[coreyoconnor]

Currently only the bare necessary to get lsp-scala running with lsp next. This uses lsp workspaces (derived from projectile) instead of sbt:find-root. I did not see a good place to integrate that. Still needed?

See also: emacs-lsp/lsp-mode#479

[rossabaker]

This is the first I've seen of lsp-next, but it looks right.

It's been a while since I've hacked on this, but maybe we don't need that sbt:root after emacs-lsp/lsp-mode#319? My projectile root is going to be my sbt:root in every case except one really irritating repo whose structure I wouldn't want to inflict on everyone else. 😄

[olafurpg]

FWIW Metals now respects the rootUri parameter in the initialize request and the working directory of the process has no impact.

[coreyoconnor]

Oof. I should really get a handle on the projectile root mechanism. I agree, at least I'm fairly sure, the sbt:root will be my projectile root in every case. I'll drop that bit. As well as the working directory of process changes.

I don't see a release schedule for lsp next. Is it worth gating it's use using featurep? Otherwise I'll update this to only support lsp-next

[rossabaker]

I haven't tried lsp-mode in a bit. Is there any downside to supporting the standard release and lsp-next via featurep while that transition completes?

[rossabaker]

Worked into #14. Thanks for the initial PR!