Remove GPUFence

[kvark]

This is a follow-up to #1169 which just removes the fences from the API, as requested - being a per-requisite for multi-queue landing.

Note: strictly speaking, GPUFence was introduced without much argument very early in the API. The main goal was - to match the native APIs (which have slightly different semantics there, btw), and to anticipate helping with future changes in WebGPU, such as buffer mapping and multi-queue synchronization. Well, now we have a clear idea of the API changes, since we are in the future, and it turns out we don't really need fences. So if we want them to stay, we need to argue for them being (re-) introduced. As it stands now, a single Queue.onCompletion() replaces fences just fine, and this is what this PR does.

---

Preview | Diff

[github-actions]

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_394fbe6

[Kangz]

LGTM in a single-queue world but onCompletion will most likely get an optional GPUSignalValue when multiqueue is added.

[kainino0x]

@jdashg suggested maybe renaming this to something like onSignalComplete since this is no longer on a fence object where the context is clear.

I said:

Alternatively maybe we should try to make this not sound like an event handler (with the word "on" at the front).

E.g. workCompleted or something

[Kangz]

onWorkCompleted? I don't know if there's a naming convention for promises in WebIDL.

[kdashg]

onPendingWorkCompleted?

[kainino0x]

As mentioned on makes it sound like an event handler. One example (more similar to our device.lost) is:
https://www.w3.org/TR/service-workers/#ref-for-dom-serviceworkercontainer-ready
but other than that most promise-returning methods are verbs, since, you know, they're methods.

[kainino0x]

Editors to bikeshed the onCompletion name