UTF-16 console support for Windows

[retep998]

This implementation does have the minor issue of not handling things correctly when a codepoint is split across multiple writes or reads, but its better than not having unicode support at all.

Adds a Windows specific struct WindowsTTY in libnative and make tty_open create that struct on Windows. Adds needed functions and constants to c_win32.rs.

Libuv still needs to be updated before #15028 can be closed.

[alexcrichton]

We're trying to keep things out of liblibc nowadays, could you add these to c_win32.rs instead?

[alexcrichton]

(inside of libnative)

[alexcrichton]

It would be nice to update libuv at the same time. If you open a PR against the rust-lang/libuv repo with the relevant libuv commit I'll push it so you can update the submodule.

[alexcrichton]

If this is a windows-specific implementation, it should probably use the windows-specific function GetConsoleMode

[retep998]

GetConsoleMode merely tells us the set of flags that we've set for the console, not whether it is or isn't a TTY. isatty does the job fine at telling whether we're attached to a TTY or just redirected to a file.

[alexcrichton]

It looks like it suffices for libuv, and I tend to not trust posix functions with file descriptors on windows, but if it's working well I guess it's working well.

[retep998]

No, setting the code page to UTF-8 does not work. I have already tested that option extensively in C++. The Windows console only supports narrow byte encodings and UTF-16.

[retep998]

Ah, so output with UTF-8 does indeed work, but I've used both SetConsoleCP and SetConsoleOutputCP and input with UTF-8 simply does not work. It just ignores the entire line of text I entered if there's any unicode in it.

[retep998]

Even still, when using UTF-8, Windows will often act buggy. For some examples:

http://social.msdn.microsoft.com/Forums/vstudio/en-US/e4b91f49-6f60-4ffe-887a-e18e39250905/possible-bugs-in-writefile-and-crt-unicode-issues?forum=vcgeneral

It is probably safer to simply use UTF-16 because that is what Windows is built around.

[retep998]

Added another commit to take into account comments by @alexcrichton

[alexcrichton]

This should not happen here. It's the responsibility of the caller to fall back to a file descriptor. This should have the same error path as the unix equivalent.

[alexcrichton]

Oh dear, sorry for being so late to this! Feel free to ping a PR whenever you update this because sadly github doesn't send out notifications when that happens.