Support POD types with bitfields

[tchebb]

Although bindgen has supported bitfields for a long time, autocxx currently forbids them in POD types (issue #1303). The main obstacle to support is the way bindgen represents bitfields, using a custom struct (emitted alongside the bindings) named __BindgenBitfieldUnit<T>, where T is the underlying storage type (e.g. [u8; 4usize] for a uint32_t bitfield).

Because bitfields are structs on the Rust side types, autocxx wants __BindgenBitfieldUnit to be POD before it'll let any struct that includes one be POD. But there are a few reasons we shouldn't/can't mark __BindgenBitfieldUnit as a POD type:

1. It's not semantically correct: POD is a property of types from C++, but __BindgenBitfieldUnit is purely a Rust-side abstraction.
2. The double underscore at the beginning of __BindgenBitfieldUnit causes our validate_ident_ok_for_cxx() to reject it, meaning it never gets added to apis when we parse bindgen's output.
3. For the same reason, cxx rejects __BindgenBitfieldUnit as a type in the bridge module.
4. Even ignoring all that, our existing struct analysis can't handle structs with type parameters at all, and our convert_type() can't handle array-type type parameters.

We can't easily fix these issues, but we can sidestep them! Like point 1 says, it doesn't make sense to treat __BindgenBitfieldUnit as a C++ type at all. So instead of trying to analyze it as one, we can treat it as what it is—a primitive type that happens to have a somewhat odd spelling on the Rust side.

This commit adds a few special cases to make analyze_pod_apis() "see through" fields of type __BindgenBitfieldUnit, treating them like the underlying storage type (taken from the type parameter) instead of like structs. And that's all we need: the (now-deleted) error message that implies cxx can't handle types with __BindgenBitfieldUnit members turns out to be wrong: cxx doesn't care at all about the names of fields inside ExternType structs, so it needs no changes.

Interestingly, we unwrap the bitfield type in exactly the same way we unwrap the bindgen marker types from #1442. We even use the same code!

This PR depends on adetaylor/rust-bindgen#15. Without it, things will mostly work, but some types that end with bitfields (including the one in the new integration tests) will fail to generate due to the opaque padding field.

If you merge this PR, please don't squash it. The commits are already split appropriately.

[tchebb]

Let me know if you think this'll have detrimental code size or correctness effects elsewhere. As per bindgen's documentation, it's the only ergonomic way to construct types with bitfields, but I can leave it out if it breaks other things.