Reconsider usage of enviroment variables

[DoctorKrolic]

The main idea of a language server protocol is to provide intellisense in as client-independent way as possible. In practice, however, language servers do often contain client-dependent elements. One of such cases is using enviroment variables. I'm not saying here, that we should get rid of them all together. Even official C# extension from MS uses enviroment variables for configuring some aspects of a language server. However, it's in our interest to maintain this LSP as client-independent as possible, so it can be used outside of our own VS Code extension (see #33). Thus, IMO, we should reconsider usage of enviroment variables and avoid them as much as possible. Ideally, enviroment variables should only be used to configure options, that must be present on server startup.

For instance, we use MSBUILD_PROJECT_TOOLS_DIR variable as a base path task cache storage. Why do we need it if we can just use relative path for that?

Another example is MSBUILD_PROJECT_TOOLS_VERBOSE_LOGGING. Do we really need to know this information on server startup or we can use standard configuration endpoint? I think the latter is sufficient for our needs.

In the end, we should question every variable we use with this model of thinking. Those variables, that can be avoided, should be deleted

[tintoy]

Yeah I agree, there has probably been a gradual accumulation of these, but the logging ones definitely do need to be there though; otherwise we cannot log anything until after the client has first connected and sent us the initial configuration (and that initial logging has proved to be essential on several occasions!). Anything that we don’t need to know until after the client first connects is fair game though.