Using `windowing-systems-graphics-apis` worlds instead of graphics-context

In a recent conversation I had with @lukewagner he proposed a different solution to the problem of connecting windowing-systems with graphics-apis.
His idea was to have a special world for each connection type, e.g. a surface-webgpu world, and a surface-frame-buffer world.
At the time I dismissed the idea because it would mean we'd need windowing-system types * graphics-api types worlds, which could grow quickly.

However, while I'm still concerned about the explosion of worlds, I think this approach would provide two advantages (besides just being simpler for developers - which Luke mentioned)

1. It would allow us to have specific options/parameters for each connection type. E.g. we could put a GPUCanvasContext there (perhaps with a different name), which would be closer to the WebGPU spec.
2. It won't require us to lock in decisions in graphics-context (e.g. managed swapchain, or providing a present method).

Given all these advantages, I'm starting to think that it's a better approach after all.

@seanisom thoughts?

Start with the proposed surface-webgpu and surface-frame-buffer worlds and compare them with the graphics-context approach described in the issue. Consider how each connection type would expose options such as GPUCanvasContext without locking in swapchain or present decisions. Done requires a documented architectural decision, but the issue does not identify implementation files or tests.