Fix for bug 1196.

This bug would cause the player to jump when jump was assigned to
Space and they closed a dialog with Space. I tested vanilla
MW for behaviour and found that Jump was the only basic input which
MW does not allow when closing dialogs (i.e. if Space is assigned to
move forward, MW will move you forward after closing the dialog).

There were two reasons for the bug:
1) OpenMW GUI does not consume UI events
2) Jump occurs so long as key is down (not only on first key down)

To minimally fix the bug, I made it so that keypress events can be
consumed by the GUI and not passed along to the player control
input manager (1). However, if the player holds space, they will still
jump (as the subsequent key held events will be captured and cause
a jump).

Unfortunately, there is no idiomatic way that I could find in the
OpenMW input manager to perform events only on key down. Instead,
I introduced a variable which tracks whether the jump key has been
pressed for the first time within the current frame (2).

Note: I was initially concerned that limiting the jump event to
KeyDown and not Key Hold would cause issues with swimming,
levitating, or variable height jumping. However, after a bunch
of testing in vanilla MW and exploration of the OpenMW codebase
I could find nothing suggesting the need to capture the jump
key being held.
I wasn't talking about only injecting events if in GUI mode, but rather to evaluate the isGuiMode condition (as used for the player controls enabled setting) before the injection and not after. Basically:

            guiMode = MWBase::Environment::get().getWindowManager()->isGuiMode();
            guiMode = guiMode && MyGUI::InputManager::getInstance().injectMousePress(mMouseX, mMouseY, sdlButtonToMyGUI(id));

This makes more sense to me. If isGuiMode is true before the injection, that means that MyGUI should consume the mouseclick. But let's say within injectMousePress, a button is clicked that closes a window and changes to game-mode. If isGuiMode is evaluated again at that point, it returns false, and player controls would be enabled even though MyGUI already consumed the event. That seems like the opposite of what we're trying to achieve.