Fix URI handling when comparing encoded and unencoded URIs

[dibarbet]

Resolves dotnet/vscode-csharp#5843

This is a 'fun' one.

Essentially the issue happened when the original didOpen for a document was received with an unencoded URI, but a followup request (for a xxx/resolve) passed in the encoded URI.

Unencoded URI:

git:/c:/Users/dabarbet/source/repos/ConsoleApp10/ConsoleApp10/Program.cs?{\"path\":\"c:\\\\Users\\\\dabarbet\\\\source\\\\repos\\\\ConsoleApp10\\\\ConsoleApp10\\\\Program.cs\",\"ref\":\"~\"}

Encoded URI:

git:/c:/Users/dabarbet/source/repos/ConsoleApp10/ConsoleApp10/Program.cs?%7B%22path%22:%22c:%5C%5CUsers%5C%5Cdabarbet%5C%5Csource%5C%5Crepos%5C%5CConsoleApp10%5C%5CConsoleApp10%5C%5CProgram.cs%22,%22ref%22:%22~%22%7D

Generally, clients are expected to be consistent when passing URIs to the server (always give the same encoded or unencoded version), see https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#uri
This is still true.

However, the issue came when roundtripping URIs sent by the server. Consider the following scenario

1. Client sends textDocument/didOpen with unencoded URI
2. Server saves associated information against the URI
3. Client asks for textDocument/codelens for the unencoded URI
4. Server responds with codelenses. The codelenses store the document URI in the code lens resolve data so when resolved we can find the document again
5. When the codelens items are serialized back to the client, the server serializes the URI using System.Uri.AbsoluteUri.
   The AbsoluteUri is always the encoded URI, so the codelens data contains the encoded URI.
   

   roslyn/src/LanguageServer/Protocol/Protocol/Converters/DocumentUriConverter.cs

   Line 20 in 9177306

   => writer.WriteStringValue(value.AbsoluteUri);

6. The client sends us a codelens/resolve request without touching the data (expected, its opaque to the client).
7. The server uses the URI from the codelens resolve data (the encoded version) to try to find the document associated with the codelens/resolve request - but System.Uri.Equals does not consider the encoded and unencoded URIs to be equal. This fails the request because we can't find the information from the prior textDocument/didOpen associated with it.

To fix this issue where the server cannot match the request for the encoded Uri to the unencoded version I considered a couple of paths

1. When we store info for the URI, we consider the unescaped and escaped version to be equal using a custom comparer
2. When serializing URIs, serialize the OriginalString property instead of the AbsoluteUri property

In this PR I chose 1. I don't believe 2 is the correct solution - the OriginalString is not always a valid URI depending on how the URI is created. For the generic LSP library converter, it cannot assume that the Uri object has a valid uri-formatted value in OriginalString (note that this change was attempted before back when we used the VS LSP libraries, and had to be reverted).