Support layer selection in vertex shaders

[kvark]

What

This corresponds to VK_EXT_shader_viewport_index_layer extension. Basic premise is that the images of the framebuffer can be array image views (i.e. 2D array views) with multiple layers (same number of layers for all image views in the framebuffer), and then the shader can select the destination layer with gl_Layer built-in.

Why

This is useful for avoiding begin/end of a render pass per layer of an array render target. For example, when rendering to 6 sides of a shadow cube map, we'd keep the render target bound and issue the same draw call multiple times per number of sides of the cube it should be visible in (selecting the side with a push constant, for example). This allows keeping all the relevant data (vertex/index buffers, pipeline) untouched.

Another important use case is Metal, where render passes have a higher cost in general. Our Metal backend already knows if it can support this capability and uses it extensively for things like image clears and blits.

This hits experimental WebRender in particular because currently the model it executes involves iteration through the layers of a render target. Being able to only start a single render pass per array target would help. cc @zakorgy @gw3583

How

Most of the task here is plumbing: checking how this extension maps to the backend-specific capabilities and what needs to be done to enable it. No actual rendering logic needs to change, I think, within the backends, since the API already allows having array render targets, and the only extra thing happening is the shader built-in gl_Layer.

It's not completely clear if spirv-cross would handle this built-in today, so that might be a roadblock.

[kvark]

Upon further investigation, it turns out that this isn't currently a performance blocker for the WebRender work. There are much lower hanging fruits to grab first... The feature is still valuable though, and should be easy to hook up.

[cwfitzgerald]

Moved this to wgpu due to gfx impending re-imagining, and this is an issue we would like to have in wgpu.