Always break out of the renderer's main loop when renderer is destroyed

It was possible that the renderthread could be waiting on the RenderView
population when we were asked to terminate resulting in a deadlock. We
now explicitly wake up the wait condition and then check for termination
criteria after waking up.

This is the first step towards having a clean application shutdown.

Change-Id: I4147843f658ae563798bcdad4d308cd5c641c9e9
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Only attempt to render if context is successfully made current

This removes warnings about QOpenGLShaderProgram not being valid in
the context during application shutdown. This was caused by the
QOpenGLContext::makeCurrent() failing due to the window being destroyed
behind our backs.

Ideally we should notify the renderer that the window has gone away.

Change-Id: I6def8afd9ad8e472fbdc3b0cf71e0cd59a1fce05
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Prevent deadlock during application shutdown

There is a potential deadlock when shutting down. The call to
QAspectManager::quit() sets the atomic ints such that they break out of
the loops in void QAspectManager::exec(). However, without this change
the inner loop gets one last iteration where it asks the aspects for
jobs to execute. In the case where the frame queue of the renderer is
already full, this blocks and if the renderer has already stopped
processing frames from the frame queue this will block forever.

Moving the processEvents() call after the job submission prevents this
by allowing the loop to exit immediately and avoiding the deadlock.

There is still more to be done as there is some crash around a mutex
still whilst destroying some other objects.

Change-Id: Iac5159095e5714dc1ba8c9ce128cb3a5aaaec90b
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>
Clean up the TLS in the QChangeArbiter

Change-Id: I38f19f17eb88d725752fe71979b9a220bb8de9be
Reviewed-by: Paul Lemire <paul.lemire@kdab.com>