installation: refactor GOPATH/GOBIN/etc configurations

[stamblerre]

There are far too many ways to set a GOPATH in this extension. We need to centralize them and provide users with common workflows to follow. Some thoughts:

• We should deprecate go.toolsGopath for Go versions over 1.11. Modules renders the reasoning behind this setting obsolete.
• We should figure out what to do with go.gopath vs. setting GOPATH in go.toolsEnvVars. Which one overrides the other? I have no idea what happens right now.
• What happens if a user sets GOBIN in go.toolsEnvVars?
• We should decide if go.inferGopath makes sense in a modules world.
• We should prioritize binaries on a user's PATH and only fallback to GOPATH/bin or GOBIN if the binary is not on the PATH.

[FiloSottile]

For standard library development I use toolsGopath to keep separate builds of the tools in case tip introduced any incompatibility. How would that use case be handled if the option is deprecated?

[stamblerre]

I believe that @hyangah has discovered that the whole "Your GOROOT has changed, analysis tools may need to be recompiled" warning (which I assume is what you're referring to?) is not really valid/necessary anymore. The majority (all?) tools should still work in codebases that use different Go versions without being recompiled.

In any case, you'd still be able to set different GOBINs in different workspaces. My thinking on this whole topic is really that we should deprecate all settings and make go.toolsEnvVars the only option (maybe with a better name).