a11y QComboBox: Problematic signal/slot activation order

This is a follow-up ticket for QTBUG-119526, s.a. discussion in the pending Gerrit change https://codereview.qt-project.org/c/qt/qtbase/+/524482 .

The crashes described in the above-mentioned bug has been fixed in this commit:

commit ecef7046245f3adee9366d3543e4ed2a09f65735
Author: Volker Hilsheimer
Date:   Fri Dec 8 16:53:51 2023 +0100

    QComboBox: inform accessibility about model change before selecting

     
    QComboBox implicitly selects the first item that gets inserted into the
    model. This happens in response to the model's rowInserted signal, at
    which point the item view might not have handled the rowInserted signal
    yet. Because of that, the view couldn't update the accessibility bridge,
    so informing accessibility about a row being selected that doens't exist
    in the bridge's representation of the table yet will result in data
    being out of sync, and depending on the bridge implementation trigger
    asserts.
     
    Fix this by explicitly updating the accessibility bridge before
    implicitly selecting the first row.

    Fixes: QTBUG-119526
    Fixes: QTBUG-118585
    Pick-to: 6.6 6.5
    Change-Id: I2830c00751b3f18feb5d9252b23823c80229fed1
    Reviewed-by: Tor Arne Vestbø
    Reviewed-by: Jan Arve Sæther

As already described in the above commit message, the order in which the slots for the rowInserted signal are processed is problematic.

The above commit fixes the problem resulting from the table representation in Qt's macOS accessibility bridge not being updated. (macOS accessibility bridge depends on QAbstractItemViewPrivate::rowsInserted to update its table representation, which may be necessary before activating other slots, but other slots were processed earlier without the above commit in place.)

However, even without the aspect of keeping Qt's a11y bridge representation of the table itself in sync, the order can still (at least in theory, don't know how relevant it is actually in practice) be relevant if AT or caches on the platform a11y layer rely on the platform equivalents of the different QAccessibleTableModelChangeEvent types.
(And they're at least bridged to equivalent AT-SPI2 events in the Linux/AT-SPI2 bridge, s. AtSpiAdaptor::notify.)

QAbstractItemModel::rowsInserted sends a QAccessibleTableModelChangeEvent::RowsInserted event and ecef7046245f3adee9366d3543e4ed2a09f65735 added sending an QAccessibleTableModelChangeEvent::ModelReset to QComboBoxPrivate::rowsInserted.

Receiving those events in the current (problematic) order could result in the new rows wrongly being added to the locally cached representation twice if ModelReset causes the locally cached representation to be reset and updated with the current data, and then RowsInserted could cause the newly added rows to be added to the cached representation once again if an incremental update of the cached representation is performed based on that event. (The rows are already present in the model at the point in time that the ModelReset event was triggered, so the cached object would already have them.)