Report CodeMirror view failures with context

[microbit-matt-hillsdon]

EditorView.update applies the new state before it redraws and does not roll back if the redraw throws, so one exception leaves the view out of step with the document and every later keystroke, click and measure throws too. Sentry then receives hundreds of follow-up events that all look alike and carry nothing to identify the first failure.

Wrap dispatchTransactions and register an exceptionSink so both the uncaught update failures and the errors CodeMirror catches itself are reported through Logging with context: user events, change spans (positions and lengths only), document versus tile-tree length, viewport, selection, composition state, navigator.language and the preceding input events as kinds without characters.

Logging.error gains an optional context object, forwarded to Sentry as extra data.

[github-actions]

Preview build will be at
https://review-python-editor-v3.microbit.org/codemirror-crash-logging/

[microbit-matt-hillsdon]

Once on staging we can e2e test this with a current crash, though it's really motivated by the tile-related ones we can't reproduce yet. Crash: https://code.haverbeke.berlin/codemirror/dev/issues/1751

[microbit-grace]

Looks good

[microbit-matt-hillsdon]

Triggered the known bug on staging and got good data back:

phase                 update
userEvents            input.type.compose.start
changes               0-181+1
startDocLength        181
docLength             1
tileLength            181
stateAdvanced         true
composing             true
compositionStarted    true
recentInput           mousedown-5339ms keydown:Meta-4944ms keydown:char-4785ms
                      keydown:Process-11ms compositionstart-11ms
                      beforeinput:insertCompositionText-9ms