Exposing the _raw variants

[lu-zero]

I stumbled upon this note:

    // It's tempting to use the [memchr crate] to optimize this. However its
    // API requires a Rust slice, which requires that all `len` bytes of the
    // buffer be accessible, while the C `memchr` API guarantees that it stops
    // accessing memory at the first byte that matches.

probably if memchr_raw is exposed it could be used by libc reimplementations like c-scape.

[BurntSushi]

I don't think this issue is enough on its own to justify the added API surface here. As it stands, this request sounds like it's asking to double the entire API surface area of the crate, which isn't great. Moreover, it's not totally clear to me that this ends up helping significantly. Doesn't libc have a bunch of other mem APIs that any reimplementation will need to provide as well?

Like to me, it just doesn't seem a great trade to double the size of an API for APIs that will basically only be used for C interop or C strings.

[lu-zero]

That's fair, it is quite a niche usage, but was worth asking :)