fix: switch to gen-lsp-types

[ribru17]

gen-lsp-types is an alternative to the lsp-types crate, with types generated via codegen from the official LSP Metamodel for correctness and completeness.

lsp-types issues fixed in gen-lsp-types:

• Add LSP 3.18 SnippetTextEdit support (proposed) gluon-lang/lsp-types#310
• Eq and Hash for all Param/Result types? gluon-lang/lsp-types#308
• The new Uri type in 0.96.0 is hard to use and have almost no interoperability gluon-lang/lsp-types#284
• Why type names of this crate don't follow the spec ? gluon-lang/lsp-types#278
• Auto-generate Protocol Bindings gluon-lang/lsp-types#277
• Derive Default for CodeActionOptions gluon-lang/lsp-types#260
• many types don't derive Hash even though they can gluon-lang/lsp-types#245
• FoldingRange.kind is limited gluon-lang/lsp-types#93

[Schottkyc137]

Hi and thanks for the PR!

I have checked out your project and I really like it. Your design decisions look solid and some of the pain points you address are ones I've also hit in lsp_types (the uri vs url decision being the main one).

That being said, my major concern with your PR is stability: I don't have an immediate problem with lsp_types and it's battle-tested. Your new crate has 5 versions in roughly two weeks. May I ask what your plan for stability is?

In any case, I'm strongly considering switching — either when I hit a feature lsp_types doesn't support, or once your crate has matured a bit.

[ribru17]

Thanks for the feedback! Lack of stability is a very valid point. In that case, maybe you should wait on this PR. I think there shouldn't be any more breaking versions coming in the future, aside from those due to actual LSP metamodel updates. That said, there might be something that comes up which requires a breaking fix, and just in case maybe we should hold off on this? That said, I'll try my best not to have this be the case, especially since the library is used in a couple of projects now.