Fix Windows platform file access to allow file sharing with external programs

[mhilbrunner]

This restores Windows platform file handling back to open files non-exlusively by default, as was the case before October 2018. (See b902a2f)

It seems back then it was unintentionally changed while fixing warnings.

This is fixed by changing the open call from _wfopen_s() to _wfsopen(), thus being able to set the file sharing constant to _SH_DENYNO while still preserving security features of _wfopen_s(), like parameter validation, meaning the warning stays fixed.

Fixes #28036.

I tested this change on Windows as extensively as I could and found no issues.

---

Details

Back then, while fixing warnings for MSVC, the function used for opening files was changed from _wfopen() to _wfopen_s() as suggested by the warning C4996. ("This function may be unsafe, consider using _wfopen_s instead.")

This new function

1. did parameter validation and thus avoided some possible security issues due to nil pointers or wrongly terminated strings
2. it also changed the default file sharing for opened files from _SH_DENYNO (which was the implicit default for the previous _wfopen()) to _SH_SECURE.

_SH_DENYNO means every opened file could be opened by other calls (like is the default on other operating systems).
_SH_SECURE means if the file is opened with READ access, others can still read the same file (but not write to it), but if it is opened with WRITE access, others can't open it at all, not even to read.

As this file sharing access is implied as default, not a parameter for either function, it seems this change was neither intended nor noticed.

This led to rarely occuring bugs on Windows, i.e. due to random access by Antivirus processes, or Godot/Windows not closing a file handle fast enough while trying to open it again elsewhere (i.e. project.godot, instead showing the Project Manager, or saving shaders/debugging the game).

What this PR does is change the file access to a third method, _wfsopen(). This is still secure, doing parameter validation and thus avoids the warning, but it allows us to actually SET the file sharing parameter. And we set it to _SH_DENYNO, as it was implicitely before the change. (And as it currently is on all non-Windows platforms, where file sharing restrictions don't exist by default.)

Warning C4996 should really have been pointing this out. It should've been _wfsopen() all along. Let's hope this banishes those annoying, rare errors for all eternity.

The only interesting lines are 116 and 316, changing the function used for opening in FileAccessWindows::_open() and FileAccessWindows::file_exists() respectively, everything else are formatting fixes.

Links:
_wfopen() docs
_wfopen_s() docs
_wfsopen() docs

[mhilbrunner]

Short explanation on sharing modes:

_SH_DENYNO: No restrictions. Multiple processes can open the file for reading, writing, or any combination thereof.
This was the default in Godot on Windows before 2018, is the default for vanilla fopen(), and is currently the case on all non-Windows platforms.
This PR changes all file access back to this.
This allows tail -f to read the file while it's being written to, but also allows e.g. multiple log writers to append to the same log file.

_SH_DENYRW: Denies other processes read and write access. Nothing allowed.

_SH_DENYRD: Denies other processes read access. They can still write.

_SH_DENYWR: Denies other processes write access. They can still read.

_SH_SECURE: The current default since 2018, before this PR. If the file is open for reading, other processes can read, but not write. If the file is open for writing, other processes can do nothing, not even read.
So if the file is open for writing, this is equivalent to _SH_DENYRW (deny all), otherwise to _SH_DENYWR (deny writing).

I debated instead changing it to _SH_DENYWR (deny writing for other processes), and in other applications would have, but that does prohibit some valid use cases (e.g. logging, as mentioned, or database uses), while I don't see any benefit for a game engine like Godot. Also, _SH_DENYNO is consistent with all other platforms, where Godot is already fine with all files being shared. Other FOSS projects also seem to favor _SH_DENYNO.

[RandomShaper]

I'm not very fond of the presence of the cosmetic changes in the same commit, but looks good to me overall.

[mhilbrunner]

I have no problem seperating those to a second commit if you want :) Just didn't bother because it was only 9 lines.

[akien-mga]

I have no problem seperating those to a second commit if you want :) Just didn't bother because it was only 9 lines.

I think it's OK in this case as it's indeed just a few lines. For more substantial changes keeping them separate is good practice indeed.

[mhilbrunner]

Seperated cosmetic changes into a second commit, added a dot :)

[akien-mga]

Thanks!

[bruvzg]

MinGW (9.0.0, GCC 11.2.0) build on macOS fails with error: '_SH_DENYNO' was not declared in this scope due to missing #include <share.h> in the file_access_windows.cpp.

[akien-mga]

MinGW (9.0.0, GCC 11.2.0) build on macOS fails with error: '_SH_DENYNO' was not declared in this scope due to missing #include <share.h> in the file_access_windows.cpp.

Fixed by #51470.

[akien-mga]

Cherry-picked for 3.4.

[akien-mga]

Cherry-picked for 3.3.3.