Expose different error types directly instead of via polymorphism - #2750

Adding to editor meeting agenda to propose this to the tacit resolution queue.
(I won't be there next week, but I support this PR or a variant where we keep a separate GPUErrorFilter enum.)

Previews, as seen when this build job started (3b7ecbd):
WebGPU | IDL
WGSL
Explainer

meeting: Doesn't seem JavaScripty - and can do the same thing with error.constructor.name today.

I hadn't thought of doing this (thanks Kelsey for thinking of it) and knowing it, I'm inclined to close this PR. Maybe I'll add a note into the spec mentioning that you can do this.

OK, I thought about this some more. Fundamentally, using error.constructor.name can work. But from a compatibility perspective, I think that using polymorphism here is more hazardous: the API has outputs of type GPUError (return value of popErrorScope, GPUUncapturedErrorEvent.error attribute). Changing the spec to add a new type to the GPUError union (start returning new types from those APIs) arguably constitutes a breaking change, as older applications wouldn't be set up to handle them.

Now, of course, returning objects with a new, never-before-seen value for error.type also constitutes a breaking change in the same way, but I think the pattern makes it less likely for applications to break down when that happens.

To improve this I've pushed a commit to this PR that changes the GPUError.type from an enum to a DOMString, to signal that it's an open type.

We discussed this on the editors call today. I'm not a fan of making the type an open string because it's something the API is returning, not that we're accepting from the developer, so we should be able to make stronger guarantees.

After talking it over some more we decided that a good path forward would be to use a common base class for the errors that had a message member so that developers can reliably use the uncapturederror event to create logs without needing to know the exact details of the error. The other place that errors may surface, push/popErrorScope(), requires that you specify the type of error you want to capture, so you have to know about the error type in advance which removes concerns about accidentally breaking if new error types are introduced.

Updated https://github.com/juj/wasm_webgpu/ to this change today. I notice that this spec change does not really help things out here, the original issues reported in #1884 are still present.