Implement Deref<Target=ByteStr> for CStr

[tamird]

This produces a deref chain of CStr -> BStr -> [u8] which is
present in the Rust-for-Linux analogues of these types.

Link: #134915
Link: Rust-for-Linux/linux#1075
Link: https://lore.kernel.org/all/20250221142816.0c015e9f@eugeo/
Link: Rust-for-Linux/linux#1146

r? @joshtriplett
cc @nbdd0121

I'm not entirely sure what it means for a stable type to deref to an unstable one - hopefully the compiler does the right thing and gates this impl on all the items being available.

[joshtriplett]

This is a really interesting idea. One potential point of concern: the deref to ByteStr uses to_bytes (rather than to_bytes_with_nul), which somewhat makes sense, but with the further deref to &[u8], is there any chance that someone will end up with a &[u8] that lacks the NUL when they expected a &[u8] that has the NUL?

This is probably fine, and I would hope that any FFI cases that require the NUL use CStr (or to_bytes_with_nul). However, I wanted to call it out as a potential hazard. If we do this, I think this deserves a mention in the documentation at least.