'.' and '..' components in relative paths in std.os.windows.OpenFile

[kubkon]

While working on #5701 and #5993 I've noticed that doing something like this on Windows:

const fd: fd_t = some_fd_thats_non_null;
const pathname = [_]u16{ '.' }; // or '..', or in fact, having '.' or '..' anywhere in the path
const new_fd = try std.os.windows.OpenFile(pathname, .{ .dir = fd });
defer std.os.windows.CloseHandle(new_fd);

will yield a runtime panic (actually, NtCreateFile will trip on OBJECT_NAME_INVALID). As far as I can work out, this is due to the presence of '.' and '..' in the pathname argument. My question is here, is there any simple way around this, or are we forced to re-implement CreateFileW where we either query the OS for the handle to cwd, or we use the .dir handle, get the canonical path to it using GetFinalPathNameByHandle, concatenate the resultant path with the specified argument path, and feed this path into NtCreateFile again (not sure if that would even work since I'd imagine we'd prepend \??\ to the resultant path which could potentially not accept '.' and '..' as valid path components)?

I'm not yet convinced whether we'd want to enable this kind of behaviour for all calls using std.os.windows.OpenFile, however, it does seem useful for std.os.realpath and std.fs.Dir.realpath, when canonicalizing the pathnames.

[squeek502]

Related: #4659

[kubkon]

Related: #4659

Nice, thanks @squeek502!

[marler8997]

Here's an easy way to reproduce this:

The compiler fails with error: Unexpected when a source file has .. on Windows:

> mkdir src
> echo "" > src\bug.zig
> zig build-obj src\..\src\bug.zig
error: Unexpected