TextEdit edit mode lost after undo...shouldn't be deselected

I will fix this as I discovered it while fixing:

#280504: Unicode surrogate-pair text cutting and pasting and undoing produces corruption

While at first I thought this issue had to do with Supplemental Unicode handling in that issue, it turns out that this problem can be produced seemingly related, these are separate issues. But I will fix it together, as they still deal with similar code.

Simplified, more minimal reproduction steps:

1. start with a text element which has text "ab".
2. Select the 'a'
3. Cut (ctrl->X)
4. Put cursor on right of 'b'
5. Paste (ctrl->V)
6. Undo (ctrl->Z)
7. Undo (ctrl->Z)
8. Select initial 'a'
9. Cut (ctrl->X)

Result, the 'a' turns into an up arrow.

Again, clicking outside of textbox seems to fix the glitch.

Even more simplified minimal steps (probably as minimal as can get):

1. start with a text element which has single character.
2. select that character (ctrl->A)
3. Cut (ctrl->X)
4. Paste (ctrl->V)
5. Undo (ctrl->Z)
6. Undo (ctrl->Z)
7. Select that character again (ctrl->A)
8. Cut (ctrl->X)

recording of the bug:

What I'm discoverring is strange...when the final cut is performed, for some reason in
void ScoreView::keyPressEvent(QKeyEvent* ev)
the line
editData.s = ev->text();
gets assigned to a string with 1 entry 0x18 which turns out to be the mysterious up arrow (http://www.fileformat.info/info/unicode/char/18/index.htm which calls it "CANCEL").

So maybe the whole problem has nothing to do with stack being corrputed? I will have to see why hat ev->txt() contains the up arrow....

So I've determined that it has nothing to do with undo stack being corrupted. Rather what it is is that upon the last undo, ScoreView's state get's set incorrectly and so ScoreView::keyPressEvent() performs a test state != ViewState::EDIT, which messes everything up, such that the user subsequently enters special characters produced by holding Ctrl and the keys. It turns out that Ctrl->X produces the special unicode character of an uparrow that means "CANCEL". And other funny chracters can be produced with other key combinations.

Here is an illustration of how after the edit mode disappears (when text no longer becomes blue), then I can press other Ctrl->key combinations like Ctrl->x, Ctrl->c, Ctrl->v, Ctrl->b which are interpreted as their actual unicode text, rather than as the special commands they should be:

So the absolute minimal repro steps can be created by causing an undo to happen. Step 1 here is

1. Double-click text element
2. Do some edit (could delete a character, could add a character, could cut a character)
3. Undo (ctrl->Z). This causes the blue coloring to disappear, indicating that textedit state is confused
4. Now any Ctrl->letter will produce one of their special unicode chars, rather than what is intended

commit 68f87040f8b92fd4a588f5997b7fbc74cb5a17be sems suspect....particularly the

score->deselectAll();

in UndoMacro::undo(). If I comment that out, then the text edit works, since it doesn't get deselected. So I guess the solution might lie in not deselecting everything if in text edit mode. I don't know quite the best wa to check if in text edit mode, though....

I figured out the problem and have a basic PR, but I honestly don't know if this is the best way to determine if user is currently editing a text box: https://github.com/musescore/MuseScore/pull/4501