added revert to normal mode in case of bad sequence of selectionchang…

[teslae1]

What this PR does / why we need it:
Fixes mouseclick at eol when in normal mode sometimes triggers visual mode.

I was able to reproduce the problem - the core issue is that vscode
sometimes issues a specific sequence of selection change events on a single mouse click.
When the error occurs the sequence of events for the single mouse click is:

1. Selection change event that selects the last character of the line

• This causes the change to visual mode

2. Selection change event that selects no characters and is at end of line

• This moves the cursor to the end of line having no characters selected

These two events leave the editor in the state which was also shown in
the issue: visual mode and no characters selected.

Which issue(s) this PR fixes
#9887

[J-Fields]

1. Selection change event that selects the last character of the line

• This causes the change to visual mode

Is there a way to detect this, and prevent it from changing the mode, rather than reverting it after the fact?

[teslae1]

1. Selection change event that selects the last character of the line

• This causes the change to visual mode

Is there a way to detect this, and prevent it from changing the mode, rather than reverting it after the fact?

I tried researching this (I agree it would be best to never end up in the bad state),
but the fact that the first event in isolation is a completely viable event
that is also dispatched when a user left clicks and drags to select the last char of a line
lead me to the conclusion that we can only detect this after the fact.

[teslae1]

@J-Fields
Hey Jason,
just wanted to know if there is anything I myself can do to move my pr's along
(including the one belonging to this conversation)
#9874
#9872
#9894
#9895
#9896

[teslae1]

Hey again @J-Fields ,
let me know if I can help in any way.
Just wanted to add to the list of pending pr's I have:
#9911
#9910
#9901