Consistent `c_char`

[Stebalien]

At the moment, there are three possible configurations for rustix on linux:

1. libc.
2. linux-raw-sys with the "std" feature.
3. linux-raw-sys without the "std" feature.

It's not currently feasible to support all three configurations, at least when the "std" feature in rustix is enabled.

1. rustix::ffi::c_char will always be the same as core::ffi::c_char (given that the "std" feature is enabled in rustix).
2. linux_raw_sys::ctypes::c_char will be i8 or u8 depending on the platform and whether or not "std" is enabled.

If I use linux_raw_sys::ctypes::c_char in my project (xattr) when, e.g., calling rustix::fs::listxattr, I'm able to support the linux-raw-sys backend both with and without the "linux-raw-sys/std" feature, but the libc backend won't work as expected. If, instead, I use rustix::ffi::c_char, I can support the libc and linux-raw-sys backends when the "linux-raw-sys/std" feature is enabled (explicitly, see #945 because it's not enabled by default) but the linux-raw-sys backend won't work without said feature.

So ether:

1. rustix needs to re-export the correct c_char. E.g., rustix::ffi::c_char needs to be linux_raw_sys::ctypes::c_char when the linux_raw_sys backend is in use.
2. linux_raw_sys needs to use core::ffi::c_char.

Ideally the second option for maximum compatibility.

[sunfishcode]

We can't use core::ffi::c_char yet because that's in Rust 1.64 and our MSRV is Rust 1.63. Fortunately, new versions of linux-raw-sys already have the code to get the same c_char as core::ffi::c_char, which fixes this bug. Unfortunately, rustix isn't using those versions yet, because they require a semver major bump. We've been putting off a semver major bump for quite a while in order to avoid hassling users with major bump churn, but this issue is a good reminder that we really should work on getting this done.

I've just now fixed several more issues on the release 1.0 checklist, and deferred a few more, getting the release closer. I'll continue to work on implementing more of those and marking the more time-consuming ones as deferred so that we can release 1.0 sooner rather than later.

[Stebalien]

By "we" I assume you're talking about linux-raw-sys because rustix does use core::ffi::c_char. But yeah, that makes sense.

I'll close this for now as it'll clearly get fixed once the release is cut.