Define/document the ways in which clients may/may not change custom-scheme URIs provided by the server

If an LSP server sends a URI like "my-foo:///C:/foo/bar" to VS Code, it will come back as "my-foo:/c%3A/foo/bar". In particular:

• the // before the authority have been removed (because the authority is empty)
• the first character of the path has been lowercased (because despite not being a file URI, VS Code's URI class has decided it is a drive letter and normalises to lowercase drive letters)

To ensure LSP clients and servers are all on the same page, it would be beneficial to document the kinds of changes client/servers are allowed to make to custom scheme URIs. In particular, the change of casing for non-file URIs seemed unexpected to me and it would be very easy for a server to that's not being tested with VS Code specifically to not handle this correctly.

(I did raise this with VS Code in the hope it was a bug, but it's apparently by design: https://github.com/microsoft/vscode/issues/202071)

Start by reviewing the URI example in the issue and the linked VS Code behavior report. Document which transformations clients and servers may or may not apply to custom-scheme URIs, including authority slashes, path casing, and percent encoding; done means the LSP guidance resolves these interoperability questions.