Behaviour of `Url::join` for Paths Starting with a Windows Drive Letter

Describe the bug

The following code I think demonstrates a potentially inconsistent treatment of paths starting with windows drive letters. In particular it is sort of treated like an absolute path, in that it overrides any path in the base url, but it is also doesn't behave like an absolute path either.

let root = Url::parse("file:///").unwrap();
println!("{}", root.join("foo").unwrap()); // file:///foo
println!("{}", root.join("/foo").unwrap()); // file:///foo
println!("{}", root.join("c:/foo").unwrap()); // c:/foo
println!("{}", root.join("/c:/foo").unwrap()); // file:///c:/foo

let root = Url::parse("file:///fiz/buz/").unwrap();
println!("{}", root.join("foo").unwrap()); // file:///fiz/buz/foo
println!("{}", root.join("/foo").unwrap()); // file:///foo
println!("{}", root.join("c:/foo").unwrap()); // c:/foo
println!("{}", root.join("/c:/foo").unwrap()); // file:///c:/foo

Looking at the standard I think c:/foo should be being interpreted as a path-relative-scheme-less-URL string which doesn't indicate that it should be treated differently from any other relative path just because it starts with a drive letter. That being said I definitely could be missing something

Start at the Url::join entry point and reproduce the examples using Windows drive-letter paths. Compare the results with the WHATWG URL writing and path-relative scheme-less URL rules linked in the issue; done means the behavior is consistent with the selected specification and covered by regression tests.