Assertion failure in FilePathParsing.swift

Assertion Failure: https://github.com/apple/swift-system/blob/main/Sources/System/FilePath/FilePathParsing.swift#L226
Test case: https://github.com/apple/swift-system/blob/main/Tests/SystemTests/FilePathTests/FilePathComponentsTest.swift#L247

```pwsh
> [IO.Path]::GetFullPath("//foo///bar/baz/")
\\foo\bar\baz\
> [IO.Path]::GetPathRoot("//foo///bar/baz/")
\\foo\bar
> [IO.Path]::GetPathRoot([IO.Path]::GetFullPath("//foo///bar/baz/"))
\\foo\bar
```

This also matches the Microsoft documentation on path normalization:
> Normally, any path passed to a Windows API is (effectively) passed to the [GetFullPathName function](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-getfullpathnamea) and normalized. There is one important exception: a device path that begins with a question mark instead of a period. Unless the path starts exactly with \\?\ (note the use of the canonical backslash), it is normalized.

_Originally posted by @compnerd in https://github.com/apple/swift-system/pull/101#discussion_r1262802765_

Start at the assertion in Sources/System/FilePath/FilePathParsing.swift:226 and reproduce the case in Tests/SystemTests/FilePathTests/FilePathComponentsTest.swift:247. Compare the parser's handling of "//foo///bar/baz/" with the Windows normalization examples in the issue. Done means the assertion no longer fails and the test reflects the expected normalized path behavior.

Written by the indexing model from the issue text.