x/tools/gopls: make it easier to query supported settings

[hyangah]

Sometimes we add custom functionalities that are not specified in the standard LSP spec.
For example, for features like vulnerability check and gc details,
we expected the clients to apply heuristics to figure out what features are available.
For example, vscode-go extension used a mix of gopls version (either from gopls version or
go version -m command, or from the version encoded in InitializeResult.serverInfo.version field),
or existence of a certain command in ServerCapabilities.executeCommandProvider.commands list,
or optimistically assume new functionalities and handle failures. These sort-of worked when custom
commands are involved.

Now we are discussing a prompt ability for go telemetry and adding a setting to control it.
VS Code adds most of the gopls settings in the InitializeParams.initializationOptions, the very
first message sent to gopls. This can be problematic if the gopls is not able to recognize the setting
yet because the gopls is currently very strict about unrecognized settings.

Some options to consider:

1. Relax gopls's behavior around unknown settings. For diagnostics and visibility, we can still let gopls
   add unused settings.

2. Require clients to delay sending such configuration until they receive InitializeResult that
   provides hints about gopls's capabilities. Currently only the version info and commands list are used,
   but we can also extend the initializeResult to include dynamically settable custom gopls settings list.

3. Require clients to figure out the capability through a side channel (e.g. gopls version, gopls api-json, ...).
   This is the currently available option and I hope we can do better than that.

[findleyr]

It seems that gopls api-json does almost exactly what we want, since it can be used to answer questions about the existence of settings, e.g. gopls api-json | jq '.Options.User[] | select(.Name = "verboseOutput")'. We could extend it to explicitly answer questions about supported settings. For example:

gopls api-json -setting "verboseOutput"

This invocation would return a JSON description of that one setting, and would have a nonzero exit value if the setting isn't supported. WDYT?

[findleyr]

@hyangah this is not necessary anymore, right, since it is implemented from VS Code via a custom command?

[findleyr]

Repurposing this issue to track the suggestion in #62573 (comment).

[findleyr]

@hyangah I'm not sure this is actionable. gopls api-json exists, and while it could be made more flexible I am hesitant to devote time improving it until there is a concrete need.

Moving this to unplanned until there is a clearer path forward.