Expose trace verbosity

[Xanewok]

This is another take on #39 (Add output channel). Currently, from what I looked, there's no way to easily capture protocol messages for debugging/overview purposes, even when running under DEV_MODE. So the PR is split into two commits.
Firstly, it allows to trace only protocol messages (either information for sent/received messages or also including the formatted contents) by setting appropriate trace verbosity property in LanguageClient (using built-in API) when ran with DEV_MODE set to true. I set it to Trace.Messages by default (info about the messages, but not including contents), because it made sense for me to display simple trace logs when run under DEV_MODE, but we could make it completely opt-in.
Secondly, it also allows to set RUST_LOG env var when running the server. Not sure if the implementation is good enough, but since the fact that you can provide RUST_LOG to the server is rarely brought up, I just wanted have it there, so people can only toy with setting the desired verbosity when they're hacking on RLS 😄 It's completely opt-in.
If we don't want these two things then maybe we can just introduce one or the other - I didn't want to submit 2 PRs for related things.

[Xanewok]

Actually I checked again and encountered #26, where setting RUST_LOG resulted with crash. To be honest it didn't occur for me even when setting RUST_LOG before running VS Code, nor did it when setting it when spawning RLS. Will still need to look it up.

[sophiajt]

You should be able to use environment variables to set this, right? I guess I'm not entirely sure what this is providing specifically.

[Xanewok]

Unfortunately I did encounter problems with RUST_LOG set for the rls, possibly polluting stdout and messing communication between the server and client. As you suggested, it'd probably be better to output the logs to a file instead, possibly implementing this on the server-side. This way we could make it work for many clients, too.
Not sure about setting lc.trace then - do you think it could still be useful somehow to display the protocol messages in the client extension?

[sophiajt]

Seems like we might want to use a different kind of logging technique than we're doing here so that we don't pollute stdout.

The protocol messages happen enough I'm not sure if they're terribly useful except for editor plugin authors. Being able to turn them on in some way sounds okay, but most devs won't want to see them I don't think.

[nrc]

Closing for now, since it sounds like this approach won't work. @Xanewok which platform are you on? This doesn't seem to be a problem for me on Ubuntu.