Add support for workspace read requests

[Mark Sujew (msujew)]

Related to microsoft/language-server-protocol#1264 (does not fully resolve it, since this PR does not include features to write into a file system - only read from it).

Adds support for the server to read files/directories/stat info from the client.

As indicated by microsoft/language-server-protocol#1264 (comment), I also thought it'd be best to start with read-only access to the file system. However, the new interfaces/types should be extendable enough to also add write requests if required later on.

Some questions/considerations:

• Right now, if the read/stat fails, the LSP returns null. Should it return a response error instead?
• I'm not entirely sure about the properties in FileSystemClientCapabilities. Does it make sense to expose each individual request type as an opt-in flag? Or is it enough to provide a read?: boolean flag (maybe extend this with a write?: boolean flag later on)?
• The FileType.unknown value results from the fact that vscode offers vscode.FileType.unknown as a possible value to return for FileStat.type. Should this be included in the protocol, or should stats/directory entries with this type simply be omitted?
• The LSP has been using folder instead of directory for the most part. Should this change align to this? I've simply used the same nomenclature as vscode does.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Mark Sujew (msujew)]

@microsoft-github-policy-service agree

[Dirk Bäumer (dbaeumer)]

Thanks. Very nice PR.

[Dirk Bäumer (dbaeumer)]

Can we make this a flag property with a bit wise implementation. Makes it easier to expand in the future.

[Mark Sujew (msujew)]

I thought about combining it with the type property, similar to how its done in vscode, but decided against it. Is this what you had in mind?

[Dirk Bäumer (dbaeumer)]

See above