[libstd]: Enable CacheHash in WASI

[kubkon]

This PR fixes #5437.

Summary of changes to achieve this:

• adds std.os.realpathat which is similar to std.os.realpath, however, it accepts a tuple (fd_t, []const u8) of args and thus works out the realpath of a relative path wrt to some opened file descriptor.

  If the input pathname argument turns out to be an absolute path, this function reverts to calling realpath on that pathname completely ignoring the input file descriptor. This behaviour is standard in POSIX and IMHO a good rule of thumb to follow.

  If the input file descriptor was obtained using std.fs.cwd() call, this function reverts to std.os.getcwd() to obtain the file descriptor's path.

• adds std.fs.path.resolveat functions which is similar to std.fs.path.resolve, however, differs in the sense that, in addition to a slice of paths, it also accepts a Dir handle with respect to which the paths should be resolved. It also issues one syscall in order to workout the path to the Dir handle.

  With std.fs.path.resolveat, it is now possible to store work_dir handle directly in CacheHash struct and workout paths to cached files wrt to it rather than wrt cwd.

• adds std.fs.path.resolveRelative function which is like std.fs.path.resolve however it resolves relative paths only, and they are always resolved to wrt ".". If the final path is resolved to "." or beyond, null is returned instead to signify this. Also, if an absolute path is passed as an argument, ResolveRelativeError.AbsolutePath is thrown. This function is particularly useful for Capsicum-like targets such as WASI.

  This commit also tweaks std.cache_hash.CacheHash to use either std.fs.path.resolveat or std.fs.path.resolveRelative (the latter used when targeting WASI). This way, we essentially got rid of any mention of CWD, and hence, it is now possible to use CacheHash struct in WASI. As a result, all tests in the said module have been enabled for WASI.

cc @andrewrk, as per usual, looking forward to your thoughts on this!

[kubkon]

@andrewrk I'm thinking of breaking up this PR into a couple smaller, or at least extracting the fdPath and realpathat fn into a separate PR. This primitive would prove helpful in implementing several missing *at syscalls on Windows with the approach being similar to the one we take in wasmtime:

1. for the specified dirfd: fd_t, query the OS for the path
2. concatenate with path_name: []const u8 to obtain the absolute path
3. issue the matching syscall that operates on paths only

What do you reckon?

[kubkon]

Closing in favour of landing in stages. Part 1 in #5701.