Improve `file://` hyperlinks support - local/remote hostname

Description of the new feature/enhancement

Currently, Windows Terminal supports the following file:// URI patterns:

• file:///C:/SomeDir/SomeFile.txt
• file://localhost/C:/SomeDir/SomeFile.txt

The following patterns are rejected with a "This link type is currently not supported" message:

• file://wsl$/Ubuntu/SomeDir/SomeFile.txt
• file://remote_host/SomeDir/SomeFile.txt
• file://local_hostname/SomeDir/SomeFile.txt

Please add support for these cases. Note that the hyperlinks (OSC 8) spec requests for the hostname to be present in file URIs.

Proposed technical implementation details

The following justification is provided in the code:

https://github.com/microsoft/terminal/blob/54dc2c4432857919a6a87682a09bca06608155ed/src/cascadia/TerminalApp/TerminalPage.cpp#L2304-L2309

After testing with ShellExecuteEx (more precisely with Process.Start with UseShellExecute in .NET), I noticed the following:

• Remote hostnames (including wsl$) are supported just fine by the shell
• The local hostname results in the following error: "The system cannot find the file specified"

Therefore, I think the Windows Terminal should:

• Substitute the hostname in the URI with localhost if it happens to match the local hostname
• Maybe also support the FQDN?
• Try to open URIs with a remote hostname as-is

This relates to #7699 and #5001.

See also the discussion in https://github.com/BurntSushi/ripgrep/issues/665 for the problems this feature would solve.

Another example of a really useful usage this would enable would be oh-my-posh WSL links:

Start at the linked hostname-handling code in src/cascadia/TerminalApp/TerminalPage.cpp around lines 2304-2309, then trace how file:// hyperlinks are opened. Compare local, remote, localhost, and wsl$ hostnames with ShellExecuteEx behavior. Done means the listed local and remote URI patterns are accepted, with local-hostname handling aligned to the issue's proposal.