Document the requirement on recomputed length for CString::from_raw

[ExpHP]

A recent Doc PR for CStr reminded me of this:

https://users.rust-lang.org/t/cstring-from-raw-danger/15340

• CString::from_raw should make it clear that the length isn't just "recomputed," but that the recomputed length must match the original length. Yes, this can be inferred from the clearly-stated invariants of the type, but I feel this is important enough to deserve a sentence all of its own in the Unsafety section of the from_raw method, because it singlehandedly cripples a very wide range of would-be use cases for CString.
• CString::into_raw should steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL. (But what should we steer them towards? Vec<c_char>, probably? Hard to create one from string data though, compared to Vec<u8>...)

[frewsxcv]

We might want to reuse some of the language from Vec::from_raw_parts:

• ptr needs to have been previously allocated via String/Vec<T> (at least, it's highly likely to be incorrect if it wasn't).
  • ptr's T needs to have the same size and alignment as it was allocated with.