Merge header-translator into bindgen

[madsmtm]

I started header-translator as a separate project from bindgen, partly because I needed to learn the libclang API (and then it was easier to start from scratch), but mostly for higher development velocity. See #85.

Nowadays, it now supports most Apple frameworks, and is in that sense "feature complete". So now it might make sense to consider merging header-translator into bindgen's nascent Objective-C support.

Apart from the Objective-C support, there are a number of very important things that I believe header-translator brings to the table compared to bindgen, and that I'd want bindgen to have as well in the end:

• A strong focus on ahead-of-time generation.
  • Including e.g. a sidecar file translation-config.toml that allows modifying what's being generated.
• Uses Clang/C++ modules to emit things in a more file-by-file manner.
  • Also avoids including dependent headers, and instead import libc/objc2/objc2-* definitions.
• Uses nullability/lifetime/... attributes.
• Automatic memory management.

I suspect that it might make sense to discuss with the bindgen maintainers, perhaps make a vision document or something, before beginning this work in earnest.

Extra notes

See previous discussion in #345 for an alternate route we could take.

We should also keep an eye on -fbounds-safety, and consider building tooling to enable running bindgen once for a bunch of different architectures/platforms, and merge the result, ala #408.

Note that we're currently very hackily parsing a lot of attributes from macro invocations, but when doing this work, it would probably make sense to try to modify upstream libclang to expose these as proper AST nodes (with all of the difficulty inherent in that).

This would allow users to link against private / non-Apple controlled Objective-C frameworks (see e.g. #501).

[madsmtm]

If someone wants to help out, the easiest point to get started on is probably adding support for nullability attributes (tracked upstream in rust-lang/rust-bindgen#1791).