core: add internal core::str_bytes module handling string-like slices

Introduce a new core::str_bytes module with types and functions which
handle string-like bytes slices.  String-like means that they code
treats UTF-8 byte sequences as characters within such slices but
doesn’t assume that the slices are well-formed.

A `str` is trivially a bytes sequence that the module can handle but
so is OsStr (which is WTF-8 on Windows and unstructured bytes on
Unix).

Move bunch of code (most notably implementation of the two-way
string-matching algorithm) from core::str to core::str_bytes.

Note that this likely introduces regression in some of the str
function performance (since the new code cannot assume well-formed
UTF-8).  This is going to be rectified by following commit which will
make it again possible for the code to assume bytes format.  This is
not done in this commit to keep it smaller.

Author: mina86

library/alloc/tests/str.rs

@@ -1972,7 +1972,7 @@ mod pattern {
         str_searcher_multibyte_haystack,
         " ",
         "├──",
-        [Reject(0, 3), Reject(3, 6), Reject(6, 9),]
+        [Reject(0, 9),]
     );
     make_test!(
         str_searcher_empty_needle_multibyte_haystack,
@@ -2008,13 +2008,13 @@ mod pattern {
         char_searcher_multibyte_haystack,
         ' ',
         "├──",
-        [Reject(0, 3), Reject(3, 6), Reject(6, 9),]
+        [Reject(0, 9),]
     );
     make_test!(
         char_searcher_short_haystack,
         '\u{1F4A9}',
         "* \t",
-        [Reject(0, 1), Reject(1, 2), Reject(2, 3),]
+        [Reject(0, 3),]
     );
 
     // See #85462

library/core/src/lib.rs

@@ -365,6 +365,8 @@ pub mod hash;
 pub mod pattern;
 pub mod slice;
 pub mod str;
+#[allow(missing_docs)]
+pub mod str_bytes;
 pub mod time;
 
 pub mod unicode;

library/core/src/pattern.rs

@@ -211,6 +211,19 @@ pub trait SearchResult<T = usize>: Sized + sealed::Sealed {
     /// Value indicating searching has finished.
     const DONE: Self;
 
+    /// Whether search should return reject as soon as possible.
+    ///
+    /// For example, if a search can quickly determine that the very next
+    /// position cannot be where a next match starts, it should return a reject
+    /// with that position.  This is an optimisation which allows the algorithm
+    /// to not waste time looking for the next match if caller is only
+    /// interested in the next position of a reject.
+    ///
+    /// If this is `true`, [`rejecting()`][Self::rejecting] is guaranteed to
+    /// return `Some` and if this is `false`, [`matching()`][Self::matching] is
+    /// guaranteed to return `Some`.
+    const USE_EARLY_REJECT: bool;
+
     /// Returns value describing a match or `None` if this implementation
     /// doesn’t care about matches.
     fn matching(start: T, end: T) -> Option<Self>;
@@ -232,6 +245,7 @@ pub struct RejectOnly<T = usize>(pub Option<(T, T)>);
 
 impl<T> SearchResult<T> for SearchStep<T> {
     const DONE: Self = SearchStep::Done;
+    const USE_EARLY_REJECT: bool = false;
 
     #[inline(always)]
     fn matching(s: T, e: T) -> Option<Self> {
@@ -246,6 +260,7 @@ impl<T> SearchResult<T> for SearchStep<T> {
 
 impl<T> SearchResult<T> for MatchOnly<T> {
     const DONE: Self = Self(None);
+    const USE_EARLY_REJECT: bool = false;
 
     #[inline(always)]
     fn matching(s: T, e: T) -> Option<Self> {
@@ -260,6 +275,7 @@ impl<T> SearchResult<T> for MatchOnly<T> {
 
 impl<T> SearchResult<T> for RejectOnly<T> {
     const DONE: Self = Self(None);
+    const USE_EARLY_REJECT: bool = true;
 
     #[inline(always)]
     fn matching(_s: T, _e: T) -> Option<Self> {