Repository: neovim
Issue: Inconsistent path handling on windows (UNC related)
Labels: bug,platform:windows,filesystem

### Problem

Windows has 2 distinct absolute [path styles](https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats):

1. Traditional DOS path `C:/some/path`
2. UNC path `//someshare/path`

Currently neovim seems to not always take this into account and some of the path handling functions end up breaking with UNC paths. 

[`vim.fs.normalize`](https://github.com/neovim/neovim/blob/master/runtime/lua/vim/fs.lua#L327) has recently been updated and now it trims (`:gsub('/+', '/')`) all continuous slashes, leaving only one. This will "normalize" UNC path to a single slash.

[`vim.uri_to_fname` ](https://github.com/neovim/neovim/blob/master/runtime/lua/vim/uri.lua#L106) and other `uri` related functions also generally don't expect UNC paths (these are used by `vim.lsp.util.locations_to_items`). `is_windows_file_uri` only expects a traditional drive/volume letter based path. But even if it matched, it has a substitution that would remove UNC path `uri:gsub('^file:/+', '')` (sort of expected, as it does not expect UNC path).

[`vim.uri_from_bufnr`](https://github.com/neovim/neovim/blob/master/runtime/lua/vim/uri.lua#L85) and [`vim.uri_from_fname`](https://github.com/neovim/neovim/blob/master/runtime/lua/vim/uri.lua#L63) also suffer from same-ish issues, where "is windows" is determined purely based on whether it is letter-based path.

[`vim.uri_to_bufnr`](https://github.com/neovim/neovim/blob/master/runtime/lua/vim/uri.lua#L127) in this case ends up creating a new buffer relative to current location.

[`path_is_absolute`](https://github.com/neovim/neovim/blob/master/src/nvim/path.c#L2392) on another hand seems to have mostly correct way to determine if path is absolute and supports traditional and UNC paths. This function is eventually called by `vim.api.nvim_buf_set_name`. So when using `vim.api.nvim_buf_set_name` it allows renaming a buffer to a valid UNC path, unlike other options.

As the functionality and outcome varies, usability of these functions is questionable. I myself have run into this when trying to create a buffer and then rename it to a "fake" path and provide it as LSP location. But since these functions interpret the paths in different ways, they end up not resolving to same thing.

I first thought of trying to fix `vim.uri_to_fname` myself, but as the issue seems a little bit broader than that one function, thought that maybe looking at this whole issue first would be beneficial. Two main questions being, whether normalization of UNC paths is correct/expected and whether more centralised path handling is on the roadmap (e.g. `uri_to_fname` utilizing `vim.fs.normalize`).

### Steps to reproduce

```
nvim --clean
:lua print(vim.fs.normalize("//GodotOnReady.Generator/GodotOnReady.Generator.GodotOnReadySourceGenerator/Partial_TextDocReferenceRepro_MyClass.cs"))
:lua print(vim.uri_to_fname("file:////GodotOnReady.Generator/GodotOnReady.Generator.GodotOnReadySourceGenerator/Partial_TextDocReferenceRepro_MyClass.cs"))

:lua vim.api.nvim_buf_set_name(vim.api.nvim_create_buf(true, true), "//GodotOnReady.Generator/GodotOnReady.Generator.GodotOnReadySourceGenerator/Partial_TextDocReferenceRepro_MyClass.cs")
:b2
:lua print(vim.api.nvim_buf_get_name(0))
```

### Expected behavior

consistent handling of UNC paths

### Neovim version (nvim -v)

NVIM v0.8.3 / NVIM v0.9.0

### Vim (not Nvim) behaves the same?

no

### Operating system/version

Windows

### Terminal name/version

N/A

### $TERM environment variable

N/A

### Installation

package manager