Bringing `OsStr` and `CStr` up to par with `str`

[clarfonthey]

Currently, OsStr provides a very rudimentary len function, which is used to determine capacity requirements for OsString. I feel like this is grounds enough to allow slicing over these strings.

The main use case for this would be storing multiple strings in the same OsStr buffer, then slicing them out based upon their lengths. This is particularly useful if you have a struct which requires multiple OsStrs but don't want to allocate a new box for each one, and know the lengths of all of them.

This is particularly useful because while CStr and str both have ways of accessing the bytes that make up the string, OsStr doesn't.

Obviously, slicing wouldn't make sense on CStr, because you can't just inject nuls into the middle of the string. However, it could also benefit from similar capacity-based functions on OsString alongside some kind of push method. Right now, you have to convert the string to a vec, mess with the string, then re-convert it into a CString to do any of this stuff.

While these types are not as widely used as String, it'd be nice if they were more consistent with String's API.

[oli-obk]

Obviously, slicing wouldn't make sense on CStr, because you can't just inject nuls into the middle of the string.

But you can return a [u8] from the slicing. Or a CStrSlice, which offers most of the convenience functions of CStr

[clarfonthey]

I think I could probably draft up an RFC for that. I'd like to bring these up to par with String, personally, and I have a few ideas on how to do it.

I'd prefer feature parity because the entire point of these classes is to avoid converting to String and back, and not providing enough features to the point where people have to convert back to String to get the methods they want isn't ideal.

I'd recommend a CStrSlice over [u8] mostly because [u8] could be perceived as containing a NUL whereas a special type wouldn't.

[aturon]

@clarcharr The libs team has long wanted to do this, but have lacked the bandwidth. See #1309 for some starting points, and feel free to ping me if you'd like to discuss further. You could even sit in on a libs team meeting to sketch out ideas, if you like.

[dtolnay]

This issue is somewhat more general than #900 as originally filed, but I believe we only need a single issue between the two. I dropped a link to this discussion in #900 and I am closing in favor of that issue.