Widgets: don't close virtual keyboard when showing a popup

When a widget looses focus, it hides the virtual keyboard. This ends up
looking clumsy when it looses focus to a popup/context menu.
The typical case is that the user is editing text (keyboard open), triggers a
copy/paste context menu (keyboard hides), closes the menu again (keyboard reopens).
This behavior is incorrect on both iOS and Android; The keyboard should stay open.

To optimize for the common case, this change will avoid closing the keyboard if the
reason for loosing focus comes from showing a popup.

Task-number: QTBUG-39981
Change-Id: I13961f872cbc4448e3318c6da8dfaa73ccba2f78
iOS: delay callbacks to UITextInput to avoid recursion

If the application calls "reset" or "commit" on the input
method (or forces active focus on some other item) from a text
changed or key pressed handler, iOS will sometimes throw
an exception. It does so because we try to change the state
of UITextInput (by calling textDidChange) while processing a
callback from the same place (insertText).

Optimally this should not happen since we would normally
post such events to Qt, not send them directly. But with
text input we cannot do this since UITextInput expects us
to update immediately upon receiving text input callbacks.
If not, word completion and spell checking will stop working.

This change will guard against recursive callbacks by delaying
callbacks to UITextInput when text/selection/first responder
changes.

Change-Id: I099f30adf1c5aba241fc833a45b423016f4ed8d0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
iOS: enabled QUIView to be first responder without opening the keyboard

When a UIView becomes first responder, the keyboard will open as well
if the view implements the protocol UITextInput. It turns out that
we can override the static interface declaration runtime by
overriding - (BOOL)conformsToProtocol:(Protocol *)protocol
This means that we can choose to say that we implement the protocol
when, and only when, the keyboard should be visible. And further, we
can then allow QUIView to become first responder without opening
the keyboard. This will make things easier later when implementing
support for native menus that use the responder chain for
delivering menu actions.

Change-Id: I24577fe48d5ec752a72d10897c1dd64cc8d2bbfc
iOS: be able to resign first responder while keeping Qt-s focus

Change-Id: If94fec232fdd4ac6b1e9b0ab57e267ec807bb95f
Add more QAction roles

Change-Id: I882c2afe4e70a37ddaae04657ca4a58d54beef63
iOS: Implement support for native menus

Change-Id: I2c7278697499aa046ac7b1240b7bc713ad1fc709
Revert "Make RCC handle bigger binaries"

This reverts commit 5395180fcb9a68b1590ce4bf29ef26745161403f.
iOS: keep track of whether the virtual keyboard should be visible

We can only show the keyboard if we can assign first responder
status to a QUIView. The problem is that such a view is only
available if a QWindow has fully constructed. So if the app
tries to open the keyboard from within the construction of
the first QWindow, nothing will happend (this can easily
happend from an apps main.qml file)

This patch will make qiosinputcontext slightly more robust in
this case and remember if the keyboard is supposed to be
visible, and show it once it has a valid QUIView.

Change-Id: I96e2ad6139e74af8593de0ae09cca4cb60687258