Make the bitmap present_method faster

[almarklein]

It would be great if we can improve the bitmap present_mode. Improving it's support and performance.

There's multiple reasons:

• We see several issues with surfaces, see Problems with creating a surface wgpu-py#688.
• There's use-cases where a surface cannot be used, e.g. Render to QtQuickWindowSurface #48.
• It would allow much more gui backends.
• It would benefit remote backends too.

The main problem right now is that when downloading the texture, we wait for it to arrive in CPU-land. A more asynchronous approach would allow this to happen while we start processing stuff for the next draw. Which means that the performance loss can become much smaller or even negligible. For this to happen we need to do things in multiple libraries:

• Rendercanvas would need to adjust its scheduling to make this possible.
• wgpu-py should get support for async callbacks.
• rendercavas' scheduling loop should regularly ping the wgpu instance.
• Pygfx probably also needs some changes.

Other possible improvements:

• For Qt, using a QGLWidget may improve the speed of presenting the image. But we should probably test this first, since Qt may have optimized its painter.drawImage() so much that it does not matter.
• For glfw, we could enter GL mode and present the bitmap that way. Would be nice if we can do that without adding extra dependencies. Loading the GL lib is not that hard, we can take some code from vispy
• Maybe we can pass the data pointer to OpenGL before unmapping the buffer, avoiding a data-copy.

[drlukeparry]

@almarklein - sounds a nice alternative to not requiring to obtain the raw_handle wgpu, this can be achieved in a future development of the rendercanvas. If you can find a method to transfer or render to a specific surface without needing to rely on QPainter class this would be helpful but also improve performance. This would open up a lot of opportunities, previously mentioned to integrate with other frameworks, including Qt.