Rework Uri.parse and Uri.toString

[jrieken]

tl;dr - This PR is about reimplementing our Uri.parse and Uri.toString to be more standard compliant (or closer to what users expect) but without breaking existing code that relies on its quirks.

The overall URI situation is unhappy because when VS Code started the "offical" URL global didn't exit yet. Therefore we have our own URI implementation - it serves us as data container for the typical uri components: scheme, authority, path, query, and fragment (see https://tools.ietf.org/html/rfc3986#section-3). To make dealing with UNC path simpler we added fsPath to our implementation. Also, our implementation of URI.toString normalises the outcome, e.g. percent encoded sequences are upper-cased, windows drive letters are lower-cased etc, and that allows its result to be used as key in hash maps.

The needs of VS Code are fulfilled with the current implementation and generally trouble free. Issues happen when "our" URIs leave VS Code, e.g to a browser to open a link. Then issues with encoding/decoding happen because we encode too much. On top, our implementation decodes on parse (whereas the WHATWG url encodes on parse) and can potentially loose data along the route by not re-encoding things.

Given tight constraints and the high risk of breakage we cannot fix all issues but the following are aimed at

• not loose data when calling parse/toString repeatedly, see Uri#parse can break path-component #45515
• not loose data when users click on links in the editor, Links in markdown are broken if url contains encoded parameters #79474
• not over-encode obvious parts, for instance query-strings like ?key=value, Support URL specific encodings (query component) #25852