Add onAnyEvent callback

[dmaluka]

Implement a radical approach to improving abilities of plugins to detect and handle various changes of micro's state: add onAnyEvent callback which is called, literally, after any event. A plugin can use this callback to compare a state after the previous event and after the current event, and thus is able to catch various events that cannot be detected using other callbacks.

This may be a crazy idea, but maybe let's try it.

Some examples of such events that can be detected with onAnyEvent but not with other callbacks:

• change of current working directory (see Plugin callbacks for commands (cd) #3234)
• switching cursor focus between a bufpane and the command bar (see Plugin callbacks for commands (cd) #3234)
• change of message text in the status bar (see Feature request, blink on command (or key press) rerun #3226 (comment))

[JoeKar]

Maybe it's worth mentioning, that the indication takes place before the update of the display is done.
Hopefully this doesn't lead to redraw-loops in the moment someone reacts to such an event, triggering an action, which then creates the next event and so on. 🤔

[dmaluka]

It is the same situation as with other callbacks, right?

[JoeKar]

In case of drawing...yes, I think so. Then it's common sense...
In case of possible cb-event-ping-pong the possible frequency could be higher, but it's up to the plugin (developer) to not shoot his self.

[dmaluka]

Generally, this should never happen, assuming that any events received by DoEvent() can be only triggered by other goroutines (and thus cannot be triggered by lua callbacks, since they run in the main goroutine).

I've briefly looked through the code to check if this is actually true... Looks like there actually is a couple of cases when the main goroutine may send an event to itself:

1. UpdateDiff() calls its callback which sends a redraw event regardless of its synchronous param value, e.g. even if this callback is running in the main goroutine.
2. Terminal.Close() (which is called from the main goroutine e.g. when the user closes a termpane via Ctrl-q + Ctrl-q) may send a job event to the shell.Jobs channel.

The 1st case probably only causes unneeded redraws. Even if the drawChan gets overfull with those extra redraw events, it will not cause a deadlock, since screen.Redraw() doesn't block but simply drops events in such case.

But the 2nd case, it seems, may cause a deadlock (very unlikely to happen in practice though), if the main goroutine is closing many termpanes (100+ termpanes) fast enough, causing the shell.Jobs channel overfull and thus blocking forever.

Both these cases seem to be worth fixing (especially the 2nd one), even though they are rather minor, - just to feel safe and clean, by guaranteeing no ping-pong ever, no deadlocks ever, no redundant events.