x/tools/gopls: Make "gopls/internal/lsp/protocol" package compatible with go.lsp.dev/protocol and make external

[mnoah1]

The gopls protocol package includes logic that would be useful for other language server implementations. There is already a go.lsp.dev/protocol package that contains significant overlap with the version of protocol included in gopls, and is depended on by several other LSP implementations for other languages that are written in Go.

Proposal would be to align gopls/internal/lsp/protocol with go.lsp.dev/protocol:

• go.lsp.dev/protocol appears to be manually maintained. The auto generation logic in gopls/internal/lsp/protocol could be moved there and go.lsp.dev/protocol becomes the single source of truth for all type and interface definitions.
• mappers and other logic for manipulating LSP related types could also be consolidated with go.lsp.dev/protocol as long as they are not go-specific
• What's left should mainly be go-specific and could then become a "go-protocol" package that is make external

[adonovan]

Yes, it would be nice if there was a high-quality stable package that provided the shell of an LSP server for language X, and we've received this request a number of times before (though I can't now find them in the issue tracker). However LSP has a very large API surface area, and because of upstream protocol evolution it often changes in ways that would be considered breaking changes in any other Go project. Furthermore, our generated Go bindings rely on a large list of special cases, for example to decide when to use a pointer type and when not, and these are decided mostly based on the history and needs of gopls. All of which is to say I think we're a long way from being able to undertake this effort.

Even publishing just the JSONRPC2 server may be a significant help (see #46187). This seems like a more likely proposition, and might in fact be the more valuable part since it is highly technical, whereas the LSP bindings are merely tedious. But currently we actually have two implementations of JSONRPC2 and have not found time to switch from the old one to the new one. So I don't see this happening very soon either. :(