Add LSP communication layer

[Krzysztof-Cieslak]

This PR is adding communication layer implementing Language Server Protocol.

Implementation status

LSP messages

• initialize - OK
• initialized - OK
• textDocument/hover - OK
• textDocument/didOpen - OK
• textDocument/didChange - OK
• textDocument/completion - OK
• completionItem/resolve - OK
• textDocument/rename - OK
• textDocument/definition - OK
• textDocument/typeDefinition - OK
• textDocument/implementation - OK
• textDocument/codeAction - OK
• textDocument/codeLens - OK
• codeLens/resolve - OK
• textDocument/references - OK
• textDocument/documentHighlight - OK
• textDocument/documentLink - In the future
• documentLink/resolve - Nope
• textDocument/signatureHelp - OK
• textDocument/documentColor - Nope
• textDocument/colorPresentation - Nope
• textDocument/formatting - ?
• textDocument/rangeFormatting - ?
• textDocument/onTypeFormatting - ?
• textDocument/willSave - Nope
• textDocument/willSaveWaitUntil - Nope
• textDocument/didSave - OK
• textDocument/didClose - Nope
• textDocument/documentSymbol - OK
• workspace/didChangeWatchedFiles - OK
• workspace/didChangeWorkspaceFolders - Nope
• workspace/didChangeConfiguration - OK
• workspace/symbol - OK
• workspace/executeCommand - In the future (fsharp.generateDoc)
• window/showMessage - OK
• window/logMessage - OK
• textDocument/publishDiagnostics - OK

Custom messages

• fsharp/signature - OK
• fsharp/signatureData - OK
• fsharp/lineLens - OK
• lineLens/resolve - OK
• fsharp/workspaceLoad - OK
• fsharp/compilerLocation - OK
• fsharp/project - OK
• fsharp/compile - OK
• fsharp/notifyWorkspace - OK
• fsharp/notifyWorkspacePeek - OK

Notes:

• Current implementation was trying to do minimal changes in the other layers of FSAC to ensure it doesn't break other clients. As such, some implementations in LSP layer looks bit clunky. If we agree that LSP is way to go for all clients, we can deprecate other communication protocols, and do bigger refactoring of Core project.
• Client is responsible for project loading/parsing/refreshing other than initial loading
• Initial project loading is done automatically if and only if there exists single solution file in the workspace, or there is no solution files in the workspace (in such case all detected projects are loaded)
• Custom endpoints are using (for messages body) PlainNotification type and string format serialized with exactly same serialization format as old JSON protocol
• workspace/didChangeWatchedFiles should be used only for removing diagnostics from the files that were deleted.
• Ionide's LineLenses needs to be implemented in client side using custom endpoints, it's too innovative for MSFT ;]

[enricosada]

maybe

Some (JsonConvert.DeserializeObject<SymbolUseRange[]> n)

is easier to ready, too many pipes with the generic

[Krzysztof-Cieslak]

Wow, green. At least I haven't broken anything ;-)

[Krzysztof-Cieslak]

Rebased on the latest master

[Krzysztof-Cieslak]

I think this is more or less ready - all endpoints I've wanted to implement are done. From Ionide point of view there are still some... interesting... things about VSCode ordering calls differently than what we've done in Ionide, I feel that lack of control will still cause us problems, but we'll work that out when the Ionide integration will be done.

I still plan to write some tests for it before merging.

[Krzysztof-Cieslak]

This is ready to merge (if CI is green) - if someone wanted to do some kind of code review, I'd welcome it, otherwise, I'll just merge it tomorrow morning and start working on Ionide integration. That should result in a huge set of fixes anyway ;-)

BTW - the new way of writing tests using LSP implementation is really nice and enables us to debug FSAC easily, we should get way more of those.

[cartermp]

Greeeeeeeeen