std: Redesign c_str and c_vec

[alexcrichton]

This commit is an implementation of RFC 494 which removes the entire
std::c_vec module and redesigns the std::c_str module as std::ffi.

The interface of the new CString is outlined in the linked RFC, the primary
changes being:

• The ToCStr trait is gone, meaning the with_c_str and to_c_str methods
  are now gone. These two methods are replaced with a CString::from_slice
  method.
• The CString type is now just a wrapper around Vec<u8> with a static
  guarantee that there is a trailing nul byte with no internal nul bytes. This
  means that CString now implements Deref<Target = [c_char]>, which is where
  it gains most of its methods from. A few helper methods are added to acquire a
  slice of u8 instead of c_char, as well as including a slice with the
  trailing nul byte if necessary.
• All usage of non-owned CString values is now done via two functions inside
  of std::ffi, called c_str_to_bytes and c_str_to_bytes_with_nul. These
  functions are now the one method used to convert a *const c_char to a Rust
  slice of u8.

Many more details, including newly deprecated methods, can be found linked in
the RFC. This is a:

[breaking-change]
Closes #20444

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

r? @aturon

[alexcrichton]

I should also point out that the entire std::ffi module is currently #[unstable] due to the fairly large refactorings that just happened. I'd think that this could become #[stable] pretty quickly after alpha is released or continue to be iterated upon.

[alexcrichton]

cc #20475 a use case for another free function, but not sure if we want a huge array of free functions here.

[aturon]

I think we should offer this convenience in ffi, something like ffi::c_str_to_string.

[alexcrichton]

I'm somewhat worried about a large array of functions popping up in "view this C string as a rust type":

• c_str_to_bytes x 2 for _with_nul
• c_str_to_bytes_with_max_size (e.g. CString should have a "within max length" constructor #20475) x 2 for _with_nul
• c_str_to_str

I think I'd be more in favor of sticking to the bare bones for now, and perhaps expanding later? After thinking a bit, I think that #20475 may be able to be handled by slice::from_raw_buf plus a search for 0, and the to_str variant may not actually come up all that often depending on the application. I suppose I'm always a fan of conservativeness, and we do tend to avoid providing too many convenience methods that are just compositions of some others.

[aturon]

Looks great overall! I think std::ffi is going to work out really nicely. A few nits, a rebase, and then r=me.