fix(wasm): End a WebKit composition after its commit - #26435

A composition open on the hidden input never ended when that input was
replaced (the same TextBox re-entered with another focus state, as a
tap does after keyboard focus) or removed while the TextBox kept focus
(accessibility handing it over to its semantic element). The browser's
compositionend for the old input is ignored on purpose, so the TextBox
stayed composing and never raised TextCompositionEnded.

End it when the input is replaced or removed.

While a composition edits the hidden input, the browser owns its value,
so a TextBox text that differs from it is written back when the
composition ends. For an edit a BeforeTextChanging handler cancelled,
that left the refused character in the input while the keyboard went
on composing: the next keystrokes were built on it and refused too, so
typing "a", a rejected "x", then "b" left Text at "a".

Write the TextBox's text back at once when the TextBox rejects an edit
without its text changing at all (a BeforeTextChanging cancel, or a
read-only TextBox), which ends the browser's composition, and end it
for the TextBox too. Anything else is still reconciled when the
composition ends, so the keyboard keeps its composition: an edit a
TextChanging handler changes, even back to the previous text (a length
limit), and a refusal past MaxLength. A conversion can then bring the
composition back within the limit (にほん to 日本 with MaxLength 2).

The hidden input under a read-only TextBox stayed editable, so a mobile
browser opened the soft keyboard for it and let the user type until the
TextBox reverted each edit. WinUI doesn't show the touch keyboard for a
read-only TextBox.

Set readOnly on the hidden input when the TextBox or RichEditBox is
read-only, and update it when IsReadOnly changes. (A read-only
RichEditBox already suppressed the soft keyboard; it gets readOnly for
consistency.) A read-only input still takes focus, a caret and a
selection, and still gets key events and copy: the browser only
refuses edits to it. Keyboard navigation, selection and Ctrl+C keep
working, since the TextBox handles the keys and the browser copies the
input's selection.

Mobile browsers show or hide the soft keyboard when an element takes
focus, not when readOnly flips on the focused one. So focus moving
between a read-only and an editable TextBox focuses a new input instead
of reusing the focused one, and IsReadOnly changing on the focused
TextBox enters a new input as focus does, except during a composition.

When the TextBox refuses an edit the browser applied to the hidden
input (MaxLength, BeforeTextChanging, read-only), the caret went back to
where the edit started only a dispatcher tick later. Until then the
TextBox and the input both had it where the refused edit left it, so a
key typed in between landed there: typing "x" (refused) then "y" in the
middle of "abc" gave "abyc" instead of "aybc".

Put the caret back while the refused edit is being applied, and push it
to the input even when it didn't change, since writing the text back
moved the input's caret. The restore a tick later is skipped on this
path: it would now move the caret of a key typed in between.

Soft keyboard sequences from an earlier round of browser IME work that
master already handles, kept as regression guards: a code-less
Backspace in a PasswordBox, a caret moved during a composition, a
composition ending on an input that was replaced, a line break typed
during a composition, a caret move in a textarea, and text set or
cleared from code during a composition.

Skia Android's EndBatchEdit synced the IME's text to the host, but an
edit the host refused (MaxLength, BeforeTextChanging) stayed in the
editable, as a refusal raises no text change to write back, and a
TextChanging handler's change wasn't written back either while the
batch ended. The keyboard kept composing on text the host doesn't have.

With the WebAssembly host's rule
(ImeSessionCoordinator.MustReturnTextToNative, given the host's text
read before the sync and the editable's text at the start of the batch),
the editable now takes the host's text at once and drops its composing
region, which ends the composition, as one change for the listeners: a
TextCompositionEnded handler that sets the text again is written after
it. The check runs only after the IME changed the text, as a
RichEditBox's text costs the document, and only while the host it synced
is still the active one, as the handlers that ran may have moved focus.
UpdateEditableStateFromHost reads the host once for the same reason.

A refused sync also put the host's caret where the IME left it in the
refused text, which the editable then took back, so the next key landed
one place late. The caret now stays where the edit started
(When_IME_Platform_Sync_Refused_Then_Caret_Stays).

Safari and other WebKit browsers commit a composition through input
events of their own, with no compositionupdate for the committed text.
Current WebKit (Editor::setComposition) dispatches them synchronously,
in one call: a commit is deleteCompositionText, insertFromComposition,
then compositionend with the committed text (the order seen on an
iPhone); an emptied preedit is deleteCompositionText, then
compositionend(""); a cancel is compositionend with the preedit alone,
keeping the text.

TextBox and RichEditBox synced the removal as a composition step of its
own: a TextCompositionChanged with the preedit gone (Text briefly
without it) or a range outside the text, then another one when the
commit came back. The removal is now reported with the insertion that
follows it, and a preedit put back unchanged isn't reported again.

Orders where compositionend comes before the input event that applies
the commit, with the preedit still selected for it or just removed,
aren't sent by current WebKit; they were asked to be covered when unoplatform#24502
was reviewed, and older WebKit versions may send them. On master, TextCompositionEnded then came while Text still
held the preedit. Such a composition now ends with the input event that
applies the commit, after the text change and TextCompositionChanged,
the order WinUI documents. Only these orders wait, so only they need
what follows: when no such event comes in the same task (Blink cancels
a composition whose text is selected with a compositionend alone), the
composition ends after the task as it would have at compositionend,
cancelled if the preedit was removed meanwhile; a next keystroke or
composition in the same task ends it first. The next composition input
event completes the composition whether or not it applied the
announced commit: no recorded order sends one that doesn't, so this
doesn't check that the commit is in place as unoplatform#24502 did.