x/tools/gopls: show unimported completions for symbol names

[stamblerre]

See the original discussion on microsoft/vscode-go#1846.

/cc @heschik @muirdm

[muirdm]

It's easy enable deep completions for unimported (but loaded) packages, but I think it will take a bit more work to make it useful in practice. I tried this out a while ago and it was just junk unimported candidates when I didn't want them, and not the right unimported candidates when I did want them.

I imagine the main challenges will be:

1. Searching for completions across all workspace packages will be relatively slow.
2. There will be too many matching candidates (e.g. there might easily be 10+ packages that have an exported function matching "Print"). In the vacuum of an empty "main.go" it looks amazing to complete straight to "fmt.Println", but in the context of a medium sized project, false positive and false negatives will be the norm.
3. There will often be normal lexical deep completion candidates that also match the query. Currently we return up to three deep completions, and these unimported deep completions will be competing with lexical deep completions for spots.

Some thoughts off the top of my head:

1. When loading workspace packages, keep track of usage counts for exported objects. When searching for completions, we first consider often used packages/objects (and stop searching once we have found X candidates). We could also use this data to rank unimported packages themselves (and other things like suggest commonly used import aliases).
2. Require the user's query to match the unimported package name. For example, to get "fmt.Print" the user would need to type "fpri", where the "f" matches "fmt". This makes the feature harder to use/discover, but would help avoid false positives/negatives.
3. Add one or two additional deep completion result slots reserved for unimported candidates. Perhaps reduce lexical deep completions to just two items and have one slot reserved for the best unimported candidate.

[myitcv]

The linked issue mentions potentially merging the results of workspace symbol. Not commenting on the sense/viability of such a thing, but rather just flagging that I'm currently working on a refactor of the workspace symbol piece.