Timeout on `Device::maintain` with `Maintain::WaitForSubmissionIndex` is ignored

[Wumpf]

Whenever Device::maintain with Maintain::WaitForSubmissionIndex times out, wgpu assumes that the specified submission index is done and initiates cleanup as-if the frame was done. This can cause crashes down the line as buffers may be freed too early (haven't confirmed this part, but seems shaky!).
There is a StuckGpu (on WaitIdleError and QueueSubmitError) but it is unused currently.

Wgpu needs to react to timeouts by not assuming the passed submission index is done and instead query the actual done frame.

---

The situation is particularly weird on WebGL where the max timeout is browser defined (and usually much lower than our hardcoded 5 seconds), see https://developer.mozilla.org/en-US/docs/Web/API/WebGL2RenderingContext/clientWaitSync, MAX_CLIENT_WAIT_TIMEOUT_WEBGL. Instead, we pass a timeout of zero, meaning that any WaitForSubmissionIndex call will pretend the frame is done. However, since freeing gl buffers that are still in use has no practical repercussions, this does not cause any crashes etc..
To make matters worse, on WebGL we can't actually block on this by calling it repeatedly, since clientWaitSync will not finish unless control is given back to the browser. Effectively meaning that we can't actually block on any particular event.

Worth noting here that blocking in this manner isn't possible at all either on WebGPU either where poll does not exist.

---

Given that poll is a pure Rust space method and not covered by the WebGPU spec I propose to return an enum for all these different failure modes and avoid any panic on StuckGpu, i.e. as far as possible not treating hitting the timeout as a crash but rather as an expected error state.

[cwfitzgerald]

Confirmed this can cause early buffer frees in #5000