Distinguish char16_t.

[adetaylor]

With a new command-line option, this ensures that char16_t is distinct from uint16_t in generated bindings. On some platforms these are distinct types, so it can be important for downstream post processors to spot the difference.

See the documentation on the new command-line option for expected behavior and usage here.

Part of google/autocxx#124.

[emilio]

Not a huge fan of adding bindgen-specific types that users are supposed to replace, but lacking something better this seems reasonable... Maybe worth an upstream issue to add char16_t to core::ffi and co? If you think it's a good idea adding a link to the code in a follow-up would be appreciated :)

[adetaylor]

Not a huge fan of adding bindgen-specific types that users are supposed to replace, but lacking something better this seems reasonable... Maybe worth an upstream issue to add char16_t to core::ffi and co? If you think it's a good idea adding a link to the code in a follow-up would be appreciated :)

Thanks for merging despite your concerns.

I think unfortunately the mess here runs deep. std::os::raw seems to lack quite a few of the integer types defined in C's stdint. char16_t is in fact uint_least16_t. But only in C! In C++, char16_t appears to be a different type again. (I only just figured this out) - "It has the same size, signedness, and alignment as std::uint_least16_t, but is a distinct type.".

Given that, it actually doesn't make any sense to add C++'s char16_t into std::os::raw, because it's not a C type, only C++.

But I think some of my comments in the previous PR need to be modified to explain that we're talking about C++'s char16_t not C's char16_t. I'll send a follow up PR...