Summary:
Both {nav Crop} and {nav Reduce Red Eye} feature a {nav Cancel} button.
While normally pressing {key Enter} or {key Space} while a button has
keyboard focus should trigger the button's action, in this case
incorrect actions were executed: {key Enter} accepted the modifications,
i.e. it did the opposite of what the label said, and {key Space} even
jumped to the next image.

For {key Enter} this can be solved by explicitely checking for keyboard
focus, which avoids the underlying problem, i.e. that
`ViewMainPage::slotEnterPressed` calls `*Tool::keyPressEvent` before
`QDialogButtonBox` had a chance to handle the event. For {key Space}
forwarding in `ViewMainPage::eventFilter` is enough to override the
default shortcut handler, since `*Tool::keyPressEvent` will implicitely
call `event->accept()`.

Note that this also prevents {key Space} from navigating to the next
image even when the buttons are not focused. We could bring that back,
but it would actually be more consistent if we did not, since the arrow
keys are also blocked when a tool is active. To still navigate away
while a tool is active, users can set a secondary shortcut for
{nav Next} to avoid getting in conflict with how {nav Space} is supposed
to work on buttons.

FIXED-IN: 18.08.1

Test Plan:
Use {key Tab} to focus any of the buttons in the {nav Crop} and
{nav Reduce Red Eye} tools, and press {key Enter} and {key Space}. Both
shortcuts should trigger the appropriate action, i.e. either {nav OK} or
{nav Cancel} depending on the button.

Press the same shortcuts while the image is focused. {key Space} should
do nothing, and {key Enter} should accept.

Reviewers: #gwenview, muhlenpfordt

Reviewed By: #gwenview, muhlenpfordt

Subscribers: ngraham, muhlenpfordt

Tags: #gwenview

Differential Revision: https://phabricator.kde.org/D14925