fix(state): improve detection of mode changing

[mehalter]

Description

This helps improve the detection of mode changes in Neovim. It makes 2 small changes.

• It seems like without scheduling the event callbacks for ModeChanged events, things can start executing out of order a bit
• It also seems like sometimes the api call for getting the mode of a current buffer lags behind what the actual mode is especially during the ModeChanged event until the event is over in some cases. This really seems like some sort of Neovim bug potentially but it is beyond me to really figure out how to debug it to formulate a real core neovim issue. To circumvent this, this takes the ModeChange event data which specifies the old mode and new mode as a source of truth and passes that to the rest of the functions

Related Issue(s)

• Fixes #787

[folke]

This will unfortunately break plugins that rely on canceling the existing operator (like flash and others). I've been looking into it myself as well and what I see is that after the mode change "t:n", the mode is n for a couple of ms, and then changes for about 50ms to t again after which it again becomes n.

I think this is probably due to some external process that gets started with something like <cmd> which wouldn't trigger ModeChange events, but which would still change the actual mode.

Need to look into a proper way of dealing with this.