Canvas interface

[almarklein]

Closes #86

The WebGPU spec defines part of the API on the canvas object. I can see how this makes sense in JS, where there is one type of canvas, under the control of the browser. But for us it makes the code a bit "entangled".

Therefore I moved these API functions to the device. One tricky part was how to do the presenting (aka swap the buffers). Then I realized that getting the texture view from the swap-chain, and presenting it, are two actions that always go in pairs. Python context managers are awesome for this, so this is what the swap-chain now uses.

So ...

• There now is a WgpuCanvasInterafce class with three methods.
• I added a test to make sure that using just this interface works, even without subclassing that class.
• The WgpuCanvaseBase subclasses the interface and ads convenience stuff.
• Clarify the docs.
• configure_swap_chain and get_swap_chain_preferred_format are now methods of device instead of canvas.
• The swap-chain has one API-thing: use it as a context manager to get the texture view to render to.

[Korijn]

Looks good. I'm not entirely sure how this would work when rendering to an image directly without a GUI but I get the impression you've thought about this already.

[almarklein]

I'm not entirely sure how this would work when rendering to an image directly without a GUI

Then you won't need any canvas stuff. You call request_adapter with canvas=None, and you never call device.configure_swap_chain().