feat(lsp): Allow passing environment variables to the language server

[cameron-martin]

This adds an extra configuration option, bazel.lsp.env, which passes extra environment variables to the language server. This is useful to enable logging, for example.

[vogelsgesang]

By the way: I have been wondering...
Should we keep everything in a monolithic extension? Or should we distribute it across multiple extensions? E.g. should the language server maybe be a separate VSCode extension?

For the current functionality in this extension (which centers around calling into Bazel into various ways), it makes sense to have it all in one place. Otherwise, code sharing would be pretty hard. But the LSP (both your Starlark language server and my bazelrc-lsp rarely invoke the Bazel binary, and don't need to share much code with this extension here.

Also see #435. WDYT? Should we work towards splitting off the language servers from this extension?

[cameron-martin]

I'm not too familiar with the trade-offs here. What would be the motivation for splitting this up?

One thing to consider is that this extension disables some inbuilt functionality if the language server is enabled, on the basis that the language server is likely to provide this. Is this sort of interaction between extensions possible? This wouldn't be an issue if this functionality was removed entirely from the bazel extension and expected to be provided by a language server.

Would each language server be expected to provide it's own extension when there are multiple implementations? If so, this would have the disadvantage of multiple similar extensions, with associated release processes etc, but the advantage of being able to do things specific to the language server, such as shipping the language server with the extension, or auto-downloading it.

User experience is another consideration. Having everything in one extension is nice from that perspective, so the user installs one extension and gets all the features in one go.