Mark str::is_char_boundary and str::split_at* unstably const.

[zachs18]

Tracking issues: #131516, #131518

First commit implements const_is_char_boundary, second commit implements const_str_split_at (which depends on const_is_char_boundary)

I used const_eval_select for is_char_boundary since there is a comment about optimizations that would theoretically not happen with the simple const-compatible version (since slice::get is not constifiable) cc #84751. I have not checked if this code difference is still required for the optimization, so it might not be worth the code complication, but 🤷.

This changes str::split_at_checked to use a new private helper function split_at_unchecked (copied from split_at_mut_unchecked) that does pointer stuff instead of get_unchecked, since that is not currently constifiable due to using the SliceIndex trait.

[rustbot]

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[okaneco]

I found the commit f621193 that added the optimization comments mentioning avoiding a panic branch and touching memory when index was 0 which you can see here, comparing 1.8, 1.9, and nightly
https://rust.godbolt.org/z/GTx4Mc3G4

I don't think the last comment line rules out const-incompatibility. It looks like it's trying to reinforce that slice.get(..i) relies on that specific early return to optimize out checks, not that using get(i) in is_char_boundary is required for the optimization.

I would assume you'd get the same optimizations if the match+get() was converted to an if-else statement, but there should probably be codegen tests to make sure the 0-constant slicing behavior is unchanged.

if index == 0 { return true; }
if index < self.as_bytes().len() {
    self.as_bytes()[index].is_utf8_char_boundary()
} else {
    index == self.len()
}