Programmatically selecting item view item breaks a11y focus

Programmatically selecting an item in an item view (QTreeView, QListView, QTableView) causes an incorrect accessible focus event for the newly selected item to be sent when the focus is somewhere else. This breaks focus tracking for assistive technology, and thus e.g. makes the Orca screen reader no longer announce events for the actually focused widget.

Sample steps to reproduce:

(s.a. attached screencast)

1. apply the attached patch 0001-DEMO-Adjust-widgetgallery-example-to-trigger-a11y-fo.patch to qtbase to adapt the "widgetgallery" example so that toggling the "Simple Input Widgets" checkbox in the example also selects an item in a QTreeView, QTableView and QListView to trigger the issue
2. run the Orca screen reader
3. build and run the (modified) widgetgallery example
4. press the tab key until keyboard focus is on the "Simple Input Widgets" checkbox
5. press the space key to toggle the checkbox (uncheck it)
6. press the space key again to toggle the checkbox again (check it again)

Actual result:

In step 5, Orca announces the newly selected table view item instead of the new state of the checkbox ("not ticked")  In step 6, Orca doesn't announce anything for the checkbox.

This is because incorrect focus events have been sent for the newly selected items on the accessibility (AT-SPI) layer that cause Orca to no longer treat the checkbox as the currently focused object.

Expected result:

In steps 5 and 6, Orca should announce the new state of the checkbox ("not ticked" in step 5, "ticked" in step 6).

Further notes:

The original scenario where I encountered this issue was with the Kate text editor: After creating a new document using Ctrl+N, moving the cursor around in the document would not result in Orca announcing the current position and text, because an incorrect focus event was sent for the item representing the document in the treeview in the "Documents" sidebar.