Feature: Add support for displaying URI instead of path.

### What's the Problem?

How paths are presented and managed by Files is inconsistent because it adheres to the old notion that software that is native to Windows does not accept forward-slashes to separate paths. However, Windows allows even decently low-level software to solely utilize the forward-slash to denote paths, rather than the backward-slash that Windows ultimately converts it to, to denote paths at or beneath the level of the file-system.

### Solution/Idea

I propose that the [“`file://`” Uniform Resource Identifier](http://wikipedia.org/wiki/File_URI_scheme) be prepended to the presented path if the path is not relative, because [the URI](http://wikipedia.org/wiki/File_URI_scheme) allows more simple formatting of local and external resources than current native implementations provide, and are easily prepended to the paths that I have previously described. Additionally, paths that contain the URI are properly parsed by software that accepts them, despite solely utilizing the forward-slash, because the URI does not accept alternative path-separators, and are more easily understood by internet-browsers. https://web.archive.org/web/https://datatracker.ietf.org/doc/id/draft-kerwin-file-scheme-07.html#unc-file-paths appears to demonstrate that Windows's [*Universal Naming Convention* (UNC) paths](https://en.wikipedia.org/w/index.php?title=Path_(computing)&oldid=1231138661#UNC:~:text=the%20%22Long%20UNC%22:-,%5C%5C?%5CUNC%5CComputerName%5CSharedFolder%5CResource,-Microsoft%20Windows%20uses) are not problematic to convert, and certainly is superseded by this format.

### Alternatives

Nothing alternative provides similar consistency.

### Priorities

I do not understand how to utilize this table, despite the template attempting to explain to me how to utilize it. I apologize.

### Files Version

https://github.com/files-community/Files/releases/tag/v3.6 per https://github.com/files-community/Files/releases/latest

### Comments

Very importantly, this obviously does not apply to relative paths, because a file URI is comprised partially of a path. That means that to prepend this to a relative path would be paradoxical.

This proposition was separated from https://github.com/files-community/Files/issues/9570#issuecomment-1214415689 because of what https://github.com/files-community/Files/issues/9570#issuecomment-1213514741 describes.

https://github.com/files-community/Files/issues/9570#issuecomment-1214415689 demonstrates that this has been accepted as not rejected, and that an intended refactor of the codebase should support it.

[The previously described Solution/Idea](https://github.com/files-community/Files/issues/9725#issue-1338304704:~:text=of%20the%20file%2Dsystem.-,Solution/Idea,-I%20propose%20that) should demonstrate the logic necessary to provide this should not be significantly difficult. (I would probably be able to implement this with regex in PowerShell if .NET didn't already support most of this.)