Improve KeyInputProc behaviour

[Zegeri]

You can now play everyone's favourite: the Nasu minigame of Yume Nikki!

The hardest issue is, without breaking anything, avoiding restarting an action-triggered event when one of its last commands is a KeyInputProc waiting for the action key. There're three relevant moments that run in the following order: the update of the main interpreter, the update of the event and the update of the game player. Suppose we have an event running a KeyInputProc waiting for the action key. This is what it should happen:

Frame	Main Interpreter	Event	Game Player
1	Player presses Action Key. Event reaches command end.	-	Action key triggers event. The interpreter ran commands from this event in this frame, so its commands are not loaded
2	-	-	Player can trigger again the event

This is what happens without the workaround 08100c3:

Frame	Main Interpreter	Event	Game Player
1	Player press Action Key. Event reaches command end.	-	Action key triggers event. The interpreter is free, so its commands are loaded
2	It runs the event's commands	-	-

This is how it looks with the workaround:

Frame	Main Interpreter	Event	Game Player
1	Player presses Action Key. Event reaches command end. ready1 = false;	ready1 = true; ready2 = false;	Action key triggers event. ready2 == false, so its commands are not loaded
2	-	ready2 = false;	Player can trigger again the event

The workaround is ugly, but it works until we come up with a better solution.

[Ghabry]

Is this some kind of inline-function declaration? Works with C++03?
Have never seen this before.

[Zegeri]

It's a function pointer. We already use it in Game_Interpreter::SetContinuation.

[Ghabry]

needs rebase