Create proper input method abstraction and expose it through a public API in QTGui

QInputContext in Qt 4.x is not sufficient for what's needed in Qt 5:

1. Input method query needs to make scene items first class citizens, current QWidget-driven model provides a suboptimal API for scene graph UIs.

• input context doesn't get information of when the focused item (that accepts input methods) changes, only when the focused QWidget changes
• in some cases input engine state/keyboard should reset when editor changes, currently that information is not provided
• current API forces unnecessary communication between scene item editors and input context
• Meego and Orbit have a custom mechanism for handling editor changes, but it should be handled inside Qt

2. QInputContext::update() should communicate what has been changed, instead of forcing the inputs to query separately if the query properties they are interested in have been updated.

• current API difficult to optimize

3. No standard way to communicate application-specific keys from editor to virtual keyboard.

• e.g. keyboard enter key turns to "send", "go" or an icon on messaging, browser app
• might not be general purpose enough justify inclusion in Qt 5
• on the other hand it sucks to create an custom channel parallel to input context just for a couple of limited cases
• this is not to say that any UI paradigm (e.g., toolbar on top of VKB) should be supported by Qt, but at least the mentioned keyboard enter key (i.e., commit action) could be considered

4. Qt 5 lacks few input method hints: e.g. MMS mode combines dialable characters only and email mode.

• some modes might be common enough to be merged to Qt 5, e.g. if seen as industry standard (available in WP7, Android, iPhone, etc.)

5. Micro-focus updates feel flaky, certainly not smooth enough for 60 fps

• the latest micro focus geometry might be invalidated by a transition animation, but not cause an update
• micro-focus in elements like WebView unreliable, plus background WebView regularly steals focus from QML elements above

6. Sending CloseSoftwareInputPanel inside QApplicationPrivate::setFocusWidget is evil.

• no way to override or customize
• when to open/close keyboard policy/UX should be decided by the platform UI style and not hard-coded in QApplication

7. Input method geometry is not available via input context.

• no way to query without a parallel API
• however, non-visual inputs need to be handled either explicitly or by providing "0 x 0, not visible" geometry

8. Per-editor input contexts.

• semi-supported, but not by QML text editing elements
• remove, label as truly optional, or actually support ~ everywhere?