QFileDialog can delete files too, not just directories

After Ic12de12ec51c20de52d040514e90be5e783add43 this functionality
was broken.  Added an autotest.

Task-number: QTBUG-34159
Change-Id: I8f41b7073dc57fea855ab87796f09e8a91520d13
Reviewed-by: David Faure <david.faure@kdab.com>
Doc: Added a link to the Qt Quick Test page

Task-number: QTBUG-33316
Change-Id: Ib8c479837cac4b7cca47b979cbb2dad0aaae6412
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Fix typo in check for MINGW_W64 version

Got introduced in 9b187bcd6a256b53cc2fb85500

Change-Id: I1d713f8309d3d8568ea836cc1d29f9dca685ac01
Reviewed-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Fix crash in QXcbDrag.

handleStatus() was called with drag==0 when releasing the mouse over the
desktop.

Task-number: QTBUG-33920
Change-Id: I553647d1e734934b7c6caf4c984683cff88f9162
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Windows: Handle WM_SYSCOLORCHANGE as theme change.

Task-number: QTBUG-34170

Change-Id: I6ca11ab67c1e2752300fc167fb8f3c4f0d9ae2b8
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Rename BlackBerry arm mkspecs to be aligned with NDK structure

The current NDK uses CPUVARDIR variable to define whether x86 or armle-v7 is used.
Therefore, the whole structure uses these two definitions to separate simulator
and device builds. Renaming blackberry-armv7le-qcc to blackberry-armle-v7-qcc
allows to directly use CPUVARDIR during Qt5 builds.
For compatibility reasons the old folder is kept and includes the new qmake.conf.

Change-Id: Ia7feeeabe16eda48140a65178af28cbb9bd085a9
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
BlackBerry: improve BPS event lifetime management

In QEventDispatcherBlackberry::select(), if an event handler called
through filterEvent() starts a nested event loop by creating a new
QEventLoop, we will recursively enter the select() method again.
However, each time bps_get_event() is called, it destroys the last
event it handed out before returning the next event.  We don't want it
to destroy the event that triggered the nested event loop, since there
may still be more handlers that need to get that event, once the
nested event loop is done and control returns to the outer event loop.

So we move an event to a holding channel, which takes ownership of the
event.  Putting the event on our own channel allows us to manage when
it is destroyed, keeping it alive until we know we are done with it.
Each recursive call of this function needs to have it's own holding
channel, since a channel is a queue, not a stack.

However, a recursive call into the select() method happens very rarely
compared to the many times this method is called.  We don't want to
create a holding channel for each time this method is called, only
when it is called recursively.  Thus we have the instance variable
d->holding_channel to use in the common case.  We keep track of
recursive calls with d->loop_level.  If we are in a recursive call,
then we create a new holding channel for this run.

Change-Id: Ib3584676d2db5a9a3754a1535d5fb6c9e14f5dbb
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>