Vendor lsp-types

[the-mikedavis]

This pulls in the lsp-types crate almost as-is from the 0.95.1 release. The only change is the crate name so far. The plan is to replace the URL type used throughout the crate with a String or Box<str> which we can parse on our end and convert to a helix-core::Uri. That is left to future work - this PR just vendors the crate.

[pascalkuthe]

There are some parts of LSP we don't use/will never support. I wonder if it's wroth stripping down the types a bit to only the functionality we actually use to reduce compile time.

I think I would also like to experiment eith improving the API in places in the future. There are some instances where I remeber wishing lsp-types exposing a different API.

[pascalkuthe]

The plan is to replace the URL type used throughout the crate with a String or Box

I think a newtpye wrapper would be convenient (or at least a type alias). That makes it easy to model URLs with a different type in the future (just replace all uses of that type) and is a bit more self-documenting

[pascalkuthe]

This may work better as an enum for example (just one example where we could improve the api)

[the-mikedavis]

I think we end up using most of the type definitions actually. We could probably drop some of the LSIF stuff like monikers but it wouldn't be a lot of code

[pascalkuthe]

hmm yeah those two I guess. I was also thinking of dynamic registration stuff. We do need it in some cases where LSP doens't offer any alternative bu t in general I don't really want to implement support for it. I still don't really see the point of it and it's very much optional for a client according to spec.

I think there is also some minor stuff that could be cleanedup even within the code we do use (but don't use some variants). I have some things in mind but it would probably make sense to just switch over to a minimally modified version first. And once that is working we can push cleanups in self contained commits