Consider removing present method becuase of incompatibility with the web

[MendyBerger]

I think we should consider removing the present() method from graphics-context because it's not really going to work on the web.

The web doesn't let you "present", you just write to the texture that's going the be presented next, and the browser presents it whenever it's ready to do so.

In the name of being compatible with the web platform, we should consider removing it. This would mean that the native hosts will now have to manage presenting on their own.

I'd just point out that it's probably possible to emulate preset behavior by not actually returning the "current-texture" returned by the browser, and instead provide our own texture that we use to copy onto the real "current-texture" when the user calls present. However, this would introduce a bunch of unnecessary overhead, so I don't think we should go there.

(@seanisom I'd love to get your thoughts)

[seanisom]

@MendyBerger is this still relevant if #55 is moved forward?

This is complex to navigate across graphics APIs, and I don't think there is a single obvious solution. As an example, Dawn does provide a Present function in its implementation, if using directly (on native): https://dawn.googlesource.com/dawn/+/refs/heads/chromium-gpu-experimental/src/dawn_native/SwapChain.cpp#136

With #55, a native window context could have a present, where a GPUCanvasContext based window could not. The challenge, then, is being able to use the same client code in a browser or native without changes.