[mono][aot] Fix support for files with non-ascii characters on windows

[BrzVlad]

Add g_fopen, g_unlink and g_rename which on windows do a utf8 to utf16 conversion and then call the corresponding wide char api.

Contributes to #83203

[BrzVlad]

cc @fanyang-mono. Shamelessly stole some code from #90436.

[fanyang-mono]

One minor optimization that Johan suggested and I wasn't able to do it correctly is that if path only contains ascii characters, it could simply use fopen. I tried adding the optimization here. But it failed the test on CI. I haven't figured out how to test it locally. So I took it out. If you could get it right, that would be great!

[BrzVlad]

I don't see this optimization having any impact in the real world, especially since we are dealing with file access which is bound to be quite slow. Unless the encoding conversion is craazy slow, which I doubt.

[fanyang-mono]

I don't really have any real world experience with the relevant API's. By looking at the code, we could avoid two calculations of g_utf8_to_utf16.
@lateralusX Do you have any insights here?

[lateralusX]

I have not done any measurements on the speed of encoding conversions on any platform and in relation to file IO its probably a small amount of time. The idea was to avoid doing the heap allocation and encoding conversion when not really needed (all characters in ascii format so standard function can be called) and since we have the logic put into a couple of g_ functions, the optimization will be isolated, simple and straightforward. I still think avoiding string encoding conversions and heap allocations when not needed is worthwhile, but I agree that in this case the frequency of calls coming into these functions will be low.

[BrzVlad]

@lateralusX I added the ascii string check to avoid utf16 conversion. Could you do a final review on this PR ?

[SamMonoRT]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).