x/tools/gopls: share workspace module with the client

[stamblerre]

Some editor clients run commands (go test, dlv, etc.), and they may want to do so from the workspace module.
We should develop a way for clients to run commands through the workspace module.

The current proposed design would be a gopls run command (on the command line) that takes a session identifier and runs a command, piping stdout/stderr back to the client. Before we set out on implementing and investigating this design, we'd like to understand the problem space a bit better. The fastest way to get something to the clients is a non-standard request to share a directory (a temporary directory whose path is based on the gopls PID) in which clients can run commands. It would only be intended for use by VS Code Go as a starting point for the investigation.

/cc @heschik @findleyr @hyangah

[findleyr]

I'll do this, since it's a natural continuation of my WIP https://golang.org/cl/263938

Plan is to continue using transient temp directories for workspace modules within gopls, but also keep an up-to-date 'latest' directory, which can be hard-coded to $TMPDIR/gopls-<pid>.workspace/.

Note that this is slightly more complicated for the daemon. We'll have to pass the forwarder pid to the daemon when creating the session, rather than just assume it's the pid of the gopls process. So this ends up being something like an intrinsic session ID anyway, which seems like a useful abstraction.

[gopherbot]

Change https://golang.org/cl/264618 mentions this issue: internal/lsp/cache: assign a static temp workspace dir to the first view