Switch to `core::ffi::c_*` for C types instead of `libc::c_*`
Based on https://github.com/immunant/c2rust/issues/294, switches to std::os::raw types by default and adds optional --use-libc-types transpiler argument.
Bindgen has an option --ctypes-prefix "some_crate::libc" that allows the user to set the path, which is convenient in embedded environments. It defaults to ::std::os::raw. I think the option would make sense for C2Rust as well.
We should update this to use the core::ffi::c_* types now that they're in core, so we don't have to worry about not being able to use the std::os::raw types in no_std crates. They're still unstable, but they look like they're going to be stabilized shortly: https://github.com/rust-lang/rust/issues/94501. They're still on nightly, but we depend on many nightly features already. I'd think the core types should be preferable to the libc ones, since you could be translating C code that doesn't use libc at all. And once the core::ffi::c_* types are stabilized, we can also use the std::ffi::c_* re-exports if we ever want to generate std instead of core.
Much of the generated code is already well usable on stable Rust; even if it's stabilized soon it'd be months until it's on stable.
I thus still like the --ctype-prefix option that is being implemented -- when used with nightly, core::ffi and std::ffi (any good reason to use that, now that core doesn't even need to be an extern crate any more?) can be good defaults.
Yeah, I agree. A --ctypes-prefix option is much more flexible, and in the future once things are stabilized, we can default to core::ffi.
core::ffi::c_* was just stabilized in 1.64: https://github.com/rust-lang/rust/issues/94501#issuecomment-1186301451.