PR# 18211 Annoying saving bug

If you perform the following sequence:
- Edit a very large text
- Save it using Ctrl+S
- Move the wheel on your mouse

You would expect the text to scroll, instead it behaves as if you had done `Ctrl+Wheel' and because the text is very large it is super slow and sometime I have to wait 20 seconds before I can recover the control.

Looks like the way we check if Ctrl is pressed is not working properly.

Actually shortcuts are always processed on the next idle (see {EV_WIDGET_IMP}.process_standard_key_press) so I'm quite a lost at why the internal state is not updated.

We could use GetAsyncKeyState but as the documentation says, this is not good as you want to be sure to handle the state of the key when the event was triggered, not when you are processing the event (a problem we had a few times when some of our implementation queries the mouse coordinate instead of using the one from the events data).

It might have to do with the fact that the saving is done in response to the key message which only exits after the save has been performed meaning that no other key events will be processed until windows retains control from the original event.  Performing the save on an idle have fix the problem as this will let the message exit so polling for new messages will retrieve the key up instead of it being potentially blocked.

We could also try firing the event on release if done on press.

My guess is that using GetKeyState is correct but somehow there is no call to `PeekMessage' or `GetMessage' that would remove the fact that Ctrl is not pressed anymore.

One might read the following blog to better understand:

http://blogs.msdn.com/b/oldnewthing/archive/2004/11/30/272262.aspx

I found out why this does this. However I don't know why I haven't noticed it earlier. The reason is that on Windows {EV_APPLICATION_IMP}.key_pressed is not correct. It uses the Win32 API GetKeyState but this does not tell you the actual key status, instead it is "the key status returned from this function changes as a thread reads key messages from its message queue". 

Meaning that it will return if the last key event we received had that key pressed or not. Which is the case when I do Ctrl+S.

The proper way to do that is to capture the WM_KEYDOWN/WM_KEYUP events and if this is one of our Ctrl/Shift/Alt we need to update the flag in EV_APPLICATION_IMP.