macOS: make Ime::Preedit cursor range surrogate-safe in setMarkedText

[William-Selna]

The macOS backend turns the IME's UTF-16 selectedRange into the UTF-8 byte offsets in Ime::Preedit by slicing substringToIndex: prefixes and measuring them with NSString::len() (lengthOfBytesUsingEncoding:NSUTF8StringEncoding). When an offset lands inside a surrogate pair the prefix ends in a lone high surrogate, which UTF-8 can't represent, and lengthOfBytesUsingEncoding: returns 0 for the whole prefix instead of the convertible part — so the offset collapses to 0.

For preedit "a😀b":

• selectedRange {2, 0} emits Some((0, 0)) instead of (1, 1) — the cursor jumps to the start and the valid "a" prefix is dropped.
• selectedRange {1, 1} emits Some((1, 0)), i.e. lower > upper. Highlighting the active clause with &preedit[range.0..range.1]
  then panics: byte index starts at 1 but ends at 0.

This is the macOS counterpart of #3967 which was fixed for Windows in #4201; the macOS backend has its own copy of the conversion that never got the same fix.

The fix drops the substringToIndex: calls and maps the UTF-16 offset to a UTF-8 offset over the already-decoded Rust string, snapping a mid-surrogate offset down to the char boundary and clamping out-of-range offsets to s.len():

fn utf16_to_utf8_offset(s: &str, utf16_offset: usize) -> usize {
    let mut utf16_pos = 0;
    for (utf8_pos, ch) in s.char_indices() {
        if utf16_pos >= utf16_offset {
            return utf8_pos;
        }
        utf16_pos += ch.len_utf16();
        if utf16_pos > utf16_offset {
            return utf8_pos; // offset splits this char's surrogate pair
        }
    }
    s.len()
}

It's monotone and location <= end for an NSRange, so the range can't come out inverted. On well-formed input it's byte-for-byte identical to the old code. And since it no longer calls any NSString range API, it also covers the out-of-bounds case the .min(len) clamp in rust-windowing/winit#4494 was added for (no NSRangeException possible) and drops two ObjC allocations per preedit update.

Malformed offsets here aren't hypothetical: rust-windowing/winit#4494 added that clamp because the native Pinyin IME sends out-of-range indices (alacritty/alacritty#8791), and rust-windowing/winit#3967 came from a non-BMP preedit (a 🐖 from the Microsoft Japanese IME) corrupting the range — same shape, one code unit over, lands mid-pair on macOS.

Tests are a #[cfg(test)] mod tests of pure functions (no AppKit, so they run on any host): the mid-surrogate snap, the previously-inverted and previously-collapsed cases, the out-of-bounds clamp, identity on well-formed input, and a monotonicity sweep. cargo build / cargo clippy -p winit-appkit are clean on macOS.