WGPUSurfaceGetCurrentTextureStatus needs a value for "surface not configured"

[kainino0x]

There's just one error case in getCurrentTexture() in the JS spec:

1. If this.[[configuration]] is null:
   1. Throw an InvalidStateError and stop.

We don't have a WGPUSurfaceGetCurrentTextureStatus to represent this currently.

typedef enum WGPUSurfaceGetCurrentTextureStatus {
    WGPUSurfaceGetCurrentTextureStatus_Success = 0x00000000,
    WGPUSurfaceGetCurrentTextureStatus_Timeout = 0x00000001,
    WGPUSurfaceGetCurrentTextureStatus_Outdated = 0x00000002,
    WGPUSurfaceGetCurrentTextureStatus_Lost = 0x00000003,
    WGPUSurfaceGetCurrentTextureStatus_OutOfMemory = 0x00000004,
    WGPUSurfaceGetCurrentTextureStatus_DeviceLost = 0x00000005,
    WGPUSurfaceGetCurrentTextureStatus_Force32 = 0x7FFFFFFF
} WGPUSurfaceGetCurrentTextureStatus WGPU_ENUM_ATTRIBUTE;

Should we add a new one, or merge with one of those?

Followup issue to #203. cc @rajveermalviya @Kangz @eliemichel

[kainino0x]

FWIW, because there is only one error case in JS, there will be only two possible return values in Wasm (Success and surface not configured).

[kainino0x]

May 23 meeting (sorry for delay):

• KN: Surface lost is probably close enough? What is surface lost anyways?
• AE: If it’s anything like device lost where something went pretty wrong, maybe we should use something different?
• KN: Should we call it something like invalid state so that we could reuse it for something else if necessary? e.g. wasm will get an InvalidState error from the JS API and have to translate it into the enum.
• AE: So maybe we use invalid state with or without implementation defined logging?
• AE: What if we just called it error or something like that?
• KN: Seems fine, but if we ever add any other errors then it might be a bit weird cause we could have different error types
• KN: Just call it WGPUSurfaceGetCurrentTextureStatus_Error

Note in #255 (comment) we decided to also use the same status for errors in struct chaining (for which we would normally use WGPUStatus_Error), so it does end up being slightly overloaded. Both can be considered "programmer error" so it seems OK.

[Kangz]

Done in #319.