Win32 FS: Rewrite (fix) vfs::host::rename, Fix fs::utime for directories

[elad335]

I've noticed that when MoveFileEx is called on a directory with opened file handles it returns an access error, it even affects one of my cellSysCache tests which was my testcase for this fix.
"Suspend" opened sys_fs file handles in such case by closing, fs::rename then reopen on the new (if succeeded) or old file path.

Partially addresses #8891 (fixes Battlefieled BC2)

Also: add guest filesystem information in kernel explorer and cellSysCache improvemenrs.

[elad335]

Added an fs::utime fix for directories based on https://docs.microsoft.com/en-us/windows/win32/fileio/obtaining-a-handle-to-a-directory to fix fs::utime usage on the pr. Requesting @bevanweiss to review the fix. (ERROR_ACCESS_DENIED was returned before)

[bevanweiss]

I think this might be a slightly bigger problem that this implementation won't resolve.
If a file is currently locked by a real PS3, then that file can be renamed, moved etc and those operations will all occur. The handles will still point at the same file, and all will be well.
Under Windows, I don't believe this is possible (typically). When a file handle is open, the path of that file is locked, and hence renaming parent paths is prevented, and moving the file is prevented.

It does appear that if (all) the files are opened with the FILE_SHARE_DELETE attribute, then renames are allowed, but I'm not sure if that extends to entire path moves, nor what kind of other problems it will raise..
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea

The policy of always specifying FILE_SHARE_DELETE appears to be supported by Microsoft (in regards to Golang libraries anyway): golang/go#32088 (comment)

It 'might' be a cleaner solution.

[elad335]

We already use this flag though, that's why renaming each file works here.

[bevanweiss]

We already use this flag though.

In fs::file::file() it appears that we don't always set this flag, although admittedly there's not many situations where we don't set it, but it would only take one file to block the move/rename.

DWORD share = 0;
if (!(mode & fs::unread) || !(mode & fs::write))
{
	share |= FILE_SHARE_READ;
}

if (!(mode & (fs::lock + fs::unread)) || !(mode & fs::write))
{
	share |= FILE_SHARE_WRITE | FILE_SHARE_DELETE;
}

[elad335]

I added a commit for it but I already tested all 3 flags always set in fs::file::open, doesnt fix it and renaming each file still works.
Im afraid this problem is related to renaming the entire paths.

[elad335]

Made vfs::host::rename atomic for it and added kernel explorer info on filesystem.

[elad335]

Can't use cpu_thread::suspend_all... (no-op here) rewritten.

[elad335]

100% accurate now.

[Nekotekina]

Some conflict

[elad335]

Conflict should be fixed.