x/tools/gopls: move "go.import.add" from vscode-go to gopls

[marwan-at-work]

Now that gopls will be on by default, vscode should delegate its remaining non-lsp functionality to gopls through nonStandardRequest, if said feature makes sense to be moved there.

Starting with the "go.add.imports" command as an example, the "Add Import" action should be a good first migration and it has a number of benefits:

1. The logic is straightforward and most of it already exists in gopls
2. The vscode-go implementation is currently using regex to parse an import statement and always adds imports to the top of the line, while gopls can more nicely add an import line in the correct place within an import block.
3. gopls can filter the list in a much smarter way than the client such as: filtering out already-imported packages, filtering out un-importable internal packages and cyclic imports.
4. The existence of this method in gopls will also open the door to other editors to use it since some of these functionalities are quite Go specific and are likely not going to make it into the LSP spec.

Once this logic is both in vscode and gopls, more custom features can be proposed to be added to gopls such as "listing all interfaces in a workspace" and "picking an interface to implement" without having to wait for a diagnostic error, etc.

If this looks okay to everyone, I have a couple of working branches for both repos I'd be happy to contribute: here and here

Thanks!

[gopherbot]

Change https://golang.org/cl/281412 mentions this issue: internal/lsp: add knownPackages and addImport as nonStandardRequests

[myitcv]

This was previously discussed, but I'm having a hard time finding the issue at the moment!

[stamblerre]

I believe the original issue is #32749.

[myitcv]

Thanks. For some reason I was only searching closed issues!

[hyangah]

I was about to file a quality issue about the quality of gopls.list_known_packages and remembered this issue.

VS Code Go's "go.import.add" (aka "Go: Add Import") was migrated to use gopls.list_known_packages a while ago. Should we continue the quality improvement discussion in this thread, or should we open another issue (because the goal for this issue is already achieved)? @findleyr

Currently gopls.list_known_packages returns results in lexicographical order which is not very useful. And it also includes unimportable packages (e.g. internal/* and vendor/*). The list can be also quite long (I think #32749 may help here).

There are also #32749 and #48545.
They are similar but not exactly capture my feature request.