libc ANSI functions must be avoided on Windows

[klutzy]

Some libc functions e.g. fopen accept or return char*. However, on Windows, they don't understand utf-8, instead they speak ANSI.
If the function returns char* which contains non-ascii, utf-8 assertion error rises. See #9418 and #9618 for actual cases. (They may be fixed by #9812)
If the function accepts char* parameter but we put non-ascii utf8, then the api fails to understand it thus returns error.

To fix it, we must avoid them and use UTF-16 alternatives e.g. _wfopen on Windows.
This requires converting utf8 into utf16 before calling libc apis.
Similarly, WinAPI with A postfix uses ANSI. We must use W functions instead.

Here is list of problematic points I know (far from complete):

• std::io uses fopen. (I don't think we should fix it now since it will be replaced by std::rt::io; libuv accepts utf8 and internally calls W-apis so it is safe)
• std::os::env uses GetEnvironmentStringsA and FreeEnvironmentStringsA.
• std::os::rename_file uses libc::rename. This will fail to rename ☆.txt to ★.txt on Windows.

[nitric1]

• std::libc::types::os::arch::extra::{LPCTSTR, LPTSTR, LPTCH} must be removed (TCHAR and its family are just for compatibility with ANSI, so not required by rust std.)
• std::rt::io::native::process::spawn_process_os (called by std::rt::io::native::process::Process::new) uses CreateProcessA. It must be changed to W (and also STARTUPINFO.)

[alexcrichton]

Closing, most functions are no longer using their ANSI equivalents, I think the only remaining use case is #13815.

More specific follow-up issues can be opened.