Expose event.getTargetRanges() in oncompositionstart (and possibly oncompositionend as well)

Problem: On Android-Chrome there's no way to capture initial composition target range (event.getTargetRanges()) when using dictation. There may be other situations like this.

Only compositionstart and compositionend are fired, no beforeinput, which I would need to determine selection (event.getTargetRanges) right before the composition started.

Reproduce:

• On a Samsung-Android phone, set cursor inside a word
• activate dictation (word gets underlined → this is the selection I'm after)
• stop dictation immediately (before making any voice inputs)

https://github.com/user-attachments/assets/7bbf1ad1-99d4-4906-afe8-edf400af6c96

Observations:

• as soon as dictation is enabled a compositionstart event is fired (now waiting for voice inputs)
• if there are no voice inputs and the dictation is cancelled by the user, still a compositionend event is fired. Assuming that at the beginning the cursor was inside the word "hello" event.data will have "hello"

Problem:

• at compositionend there's no way for me to set the selection to what should be replaced (the word that gets underlined initially)
• in my editor this means i have to assume a collapsed selection (the cursor before dictation was enabled), which will insert the word from which the composition started again at the current cursor position.

Solution ideas:

• Expose event.getTargetRanges in compositionstart event. Then i can capture the initial range that should be replaced (the word that has been underlined)
• Change implementation so event.data is "" when nothing has been dictated
• Only fire compositionstart event when something actually has been dictated.

Start by reviewing the compositionstart and compositionend behavior described in issue #511, especially event.getTargetRanges() and event.data during Android Chrome dictation. Compare the three proposed solutions and determine which behavior the editing specification should define. Done means reaching agreement on the intended event API or behavior and documenting the resulting specification change.