Remove inputSlot member from WebGPUVertexInputDescriptor - #151

We can enforce that they're parallel by making a new object which holds both items.

If we did this, it would probably make sense to use it in setIndexBuffer, copyBufferToBuffer and possibly BufferCopyView and BufferBinding too.

What's the reasoning for allowing holes in setVertexBuffers? It seems that it could be trivially replaced by multiple calls that don't have holes.

Have we figured out whether holes in setVertexBuffers unbind the buffer resource, or leave the old resource bound? If we leave the old resource bound, if I destroy the buffer, will the validation layer complain? How can I explicitly unbind the resource?

My recommendation, which is a bit bizarre, is that a hole/undefined means "leave existing resource", explicit null means "undefined", and we remove the startSlot parameter from setVertexBuffers, meaning that someone can use undefined for the same purpose. undefined is more flexible.

separating undefined and null seems like a recipe for troubles in WASM land

In principle I like being able to distinguish "keep" and "clear" but distinguishing null and undef/hole is just too unexpected IMO. In the meeting I think we decided for now that null/undef/hole would clear, and if you don't want to clear you just have to do multiple setVertexBuffers calls.

We could also disallow undef/hole and allow only null, if that would be less confusing.

Or I suppose we could do:

enum WebGPUSetVertexBuffersEntry { "unset", "keep" };
partial interface WebGPURenderPassEncoder {
    void setVertexBuffers(u32 startSlot,
        sequence<WebGPUBuffer | WebGPUSetVertexBuffersEntry> buffers,
        sequence<u32?> offsets);
};

Maybe in that case it would be better startSlot entirely and expect the full range to be passed? Otherwise we could accept ranges for keep/clear to reduce the amount repeated values.