[13.x] Fix multibyte case-insensitive matching in Str::replace and Str::remove

[marekmiklusek]

Str::replace() and Str::remove() with $caseSensitive = false delegate
to str_ireplace(), which only case-folds ASCII characters. Multibyte
characters are never matched case-insensitively:

Str::replace('ž', 'X', 'Žltý kôň', false);     // "Žltý kôň" — nothing replaced
Str::replace('KÔŇ', 'pes', 'žltý kôň', false); // "žltý kôň" — nothing replaced
Str::remove('ž', 'Žltý', false);               // "Žltý" — nothing removed

This is inconsistent within the class itself -> Str::contains() considers
the same strings a case-insensitive match:

Str::contains('Žltý', 'ž', ignoreCase: true); // true

ASCII-only search terms keep using str_ireplace() exactly as before.
Multibyte terms are matched via preg_quote + /iu patterns with a callback
replacement, replicating str_ireplace() array pairing and sequential
semantics. Subjects that are not valid UTF-8 fall back to str_ireplace(),
preserving the previous behavior.

[taylorotwell]

Agent review

Blocking

• src/Illuminate/Support/Str.php:1326 — An invalid UTF-8 search term such as "\xFF" reaches the /u pattern, producing a warning and returning null instead of preserving str_ireplace() behavior.
• src/Illuminate/Support/Str.php:1325 — An earlier replacement can introduce invalid UTF-8, causing a subsequent replacement to return null; for example, replacing ['ž', 'é'] with ["\xFF", 'x'] in 'ŽÉ'.

Should Fix

• src/Illuminate/Support/Str.php:1304 — Selecting PCRE based on the combined search terms changes ASCII-term behavior in mixed arrays, so adding 'ž' makes an existing 's' term unexpectedly match Unicode 'ſ', contrary to the stated compatibility goal.
• src/Illuminate/Support/Str.php:1326 — PCRE /iu uses different case-folding semantics from Str::contains()’s mb_strtolower(), so replacements match pairs such as 'ſ'/'S' and 'Σ'/'ς' that contains(..., ignoreCase: true) rejects.

Consider

• tests/Support/SupportStrTest.php:949 — Add malformed UTF-8 and mixed ASCII/multibyte search cases to cover the fallback and compatibility guarantees described by the PR.

[marekmiklusek]

Thanks for the thorough review, all addressed:

• Invalid UTF-8 (both blocking points): all inputs (search terms,
  replacements, subject) are now validated upfront; if anything is not valid
  UTF-8, the whole call falls back to str_ireplace(), preserving previous
  behavior exactly. Covered by adversarial fuzzing with malformed bytes in
  every position (0 nulls, byte-identical to native).

• Mixed arrays: PCRE is now selected per term, not per call, ASCII terms
  always use str_ireplace(), so adding a multibyte term no longer changes
  their semantics (test added with ſ).

• Case-folding vs contains(): implementing replacement via
  mb_strtolower() folding isn't sound, some folds change string length
  (İ → i̇), so folded offsets can't be mapped back to the original for
  splicing. PCRE simple folding only applies to genuinely multibyte terms
  now, and for the divergent pairs (ſ/S, ς/Σ) it matches a superset
  of what contains() accepts. Happy to adjust if you'd prefer different
  semantics here.