ImportC: When targeting Windows, define wchar_t as wchar.

[just-harry]

The purpose of ImportC is to make it convenient to use C libraries in D.

Presently, ImportC does not handle C's wchar_t pseudo-type in any special way, thus wchar_t will be defined as an integer type by stddef.h.
Consequently, when C code that uses wchar_t is imported into D, uses of wchar_t will translate into uses of a D integer type.

This is jolly for C, as C will happily convert string-literals to contiguous-integer-spans.
D, unlike C, will not happily convert string-literals to contiguous-integer-spans: in D, character types are distinct from integer types, unlike in C.

The ultimate result of this is that when a user attempts to use ImportC to #include <windows.h> (or some other header) and whip up a "Hello, World!", they can't simply:

MessageBoxW(null, "Hello, World!", "ImportC rocks!", MB_OK);

they instead have to:

MessageBoxW(null, cast(const(ushort)*)"Hello, World!"w.ptr, cast(const(ushort)*)"ImportC sucks!"w.ptr, MB_OK);

Mocking ImportC and D on the orange site afterwards is an optional follow-on step.

This is an objectively horrible user-experience, and should be remedied.

---

This PR makes D's character types available to C via three aliases in the __builtins module: __importc_char; __importc_wchar; __importc_dchar.
(__importc_char is somewhat superfluous, but it's provided for consistency and ease of code-generation.)

On Windows, wchar_t is an unsigned 16-bit integer which represents a UTF-16 code-unit. MSVC goes a step further and defines wchar_t/__wchar_t as built-in compiler-provided types.

Windows' and MSVC's definition of wchar_t matches D's definition of wchar.
Thus, in importc.h, when targeting Windows, this PR typedefs wchar_t as __importc_wchar and defines _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED as 1 appropriately.
If _MSC_VER is defined, __wchar_t is also typedef-ed so as to match MSVC's behaviour.

---

The reason why I began this PR's description with ImportC's raison d'être and a user story in an obnoxious patter is because a previous attempt to handle wchar_t in ImportC was rejected/abandoned—mainly due to concerns about its implementation, and its mishandling of non-Windows wchar_t.

I think this PR's way of implementing wchar_t should be fine: typedef <type> wchar_t; is how wchar_t is typically defined in stddef.h.

Likewise, this PR is something of a Pareto implementation as it simply does not do anything about wchar_t on non-Windows targets.
Outside of Windows, wchar_t can be four bytes, or two bytes, or one byte, or it could be something else! Moreover, it can be signed or unsigned.
Thus, handling wchar_t on non-Windows platforms will require a more complicated/involved solution.

However, given that usage of wchar_t is much more common on Windows than it is on other platforms (I'm asserting this without evidence): I think handling wchar_t on Windows, and engaging the Somebody Else's Problem field for wchar_t elsewhere, is highly beneficial to ImportC's usability.

P.S. Sorry for the wall of text. Thank you for reading.

[rikkimax]

Can confirm, reading C2y the spec is, well let's just say you want to do that with a clear head.

Matching MSVC should be a good place to begin.