[PATCH 1/5] include: Fix undefined char16_t with -DWINE_UNICODE_CHAR16.

[Puetz Kevin A]

> > In c++11 char16_t is a built-in fundamental type, but in c11 it is a
> > typedef from <uchar.h>
> 
> 
> I was assuming that WINE_UNICODE_CHAR16 is mostly for C++, it doesn't
> seem very useful in C. Is there a reason it's needed?

I don't know if I'd go as far as *needed*, but C11 does have both char16_t and u"", 
so WINE_UNICODE_CHAR16 is at least useful in C too. It allows you to use -DUNICODE 
and have TEXT("...") macros that match the Foo-> FooW functions just like in MSVC,
without requiring -fshort-wchar (which beaks ABI for libc and other libraries)
 
> If the concern is that things break when it's defined, maybe we could change
> checks to make it no-op in C:
> 
> #if defined(WINE_UNICODE_CHAR16) && defined(__cplusplus)

Yes, that was my main concern. Usually one sets the same #defines for C and C++, 
so if you're setting it for C++ the headers end up not working in C by breaking
include-what-you-use and referencing an undefined type.

> We'd then typedef WCHAR to unsigned short, like we usually do. uchar.h
> uses unsigned short as well, so the result should be the same without
> introducing an additional includes.

That could work too, especially since in C char16_t is no* a distinct type
(and there's no function-overload mangling). Once you have <uchar.h>, char16_t
is "the same type as uint16_t", which is almost certainly unsigned short anyway.
So it's just a different route to the same result. And, since u"" *is* a built-in,
one could even still offer TEXT macros for C11 in the final #else.

e.g. a shape like the following

#if defined(WINE_UNICODE_NATIVE)
	typedef wchar_t WCHAR
	#define TEXT(x) L ## x
#elif defined(WINE_UNICODE_CHAR16) && defined(__cplusplus)
	typedef char16_t WCHAR
	#define TEXT(x) u ## x
#else
	typedef unsigned short WCHAR
	#if __STDC_UTF_16__ /* C11 */ 
		#define TEXT(x) u ## x
	#endif
#endif

It's a little less more complex (since you need to know how char16_t
Is defined to argue that u"" matches this WCHAR), but I think it would work
for any compiler that actually has a 16-bit unsigned integral type, and
anything so exotic it doesn't can't really plausibly support wine.