Replace libc functions with WinAPIs on Windows

[klutzy]

We use libc functions on various Windows routines, but they are just convenient wrappers of WinAPI and there's usually no critical reason to use them.

Also, the wrapper has its own runtime state so it adds additional complexity, so it's better to use WinAPI than libc functions in general.
For example, msvcrt has libc errno variable, but it's not Windows' native error code value (GetLastError()) therefore unrelated to std::os::errno().
Another example is that msvcrt manages its own "C locale", distinct to Windows locale.

Here's some libc uses (not complete):

• rt/rust_builtin.c: e.g. gmtime, localtime. (seems like they are unused now)
• liballoc/heap.rs uses malloc, realloc, free if jemalloc is disabled. HeapAlloc is better?
• libstd/sys/windows/: e.g. fs.rs uses open_osfhandle.

See also Support: Win32 Equivalents for C Run-Time Functions.

[retep998]

I don't know why we insist on providing malloc for interaction with C libraries when msdn explicitly states:

The malloc function has the disadvantage of being run-time dependent.

I feel that if users want to do FFI with C libraries they are responsible for binding the appropriate allocation methods and ensuring they work correctly. Rust should not try to guarantee that the allocator it uses is compatible with non-Rust libraries when there are a plethora of incompatible allocators and even malloc itself is runtime dependent.

[alexcrichton]

I believe that this has basically been done to the fullest extent possible, so yay!