Hook up DidChangeConfiguration from client

[Cosifne]

Linked the server to client to use the DidChangeConfiguration and workspace/configuration to update the configuration value.
Some other change:

• Add a few options I feel should be meaningful in the Lsp world.
• Add a unit test to guard the workflow.

The model used is the LSP pull model from the server, it is done in this way.

1. When initialized, refresh all the options.
2. When the client notices us there is a change via DidChangeConfigurationParams, refresh all the options again.

The section sends to the client is in this pattern:

1. Option is a single value option. {optionGroupName}.{optionName}
2. Option is per language value option. The server will ask the client the value for C# and VB. The format would be
   {csharp|visual_basic}.{optionGroupName}.{optionName}
   It is done in this way because I think Roslyn server is CSharpVisualBasicLspServer, so the server should ask all the options for both languages. It is the client's responsibility to figure out which language should be supported. If the client only support C# or VB, it should give empty value to server for the supported language options.

[tmat]

Why do we need "supported" options? Why not just allow any options?

[Cosifne]

Do you mean here we don't care if the options is meaningful to the cilent not and just asking it for all the options?
If case the client doesn't have that, (it might return null), we just ignore the value and fall back to our default value?

[tmat]

pretty much

[Cosifne]

Tag @tmat and @dibarbet to review

[Cosifne]

cc @jasonmalinowski

[dibarbet]

Mostly all seems reasonable - some minor feedback.

[Cosifne]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[dibarbet]

I'm good with this

Tomas is OOF now, and I have synced with him before he left, as long as David is fine with the change he is also fine with that