[shaders] Expose a binding index set per target language

[armansito]

vello_shaders exposes a list of resource binding types for each
compute stage. This list contains only the bindings that are
actually reachable (obeying WebGPU WGSL validation rules). The
list also contains only the types and no index information is
provided; instead the elements are provided in their order of
declaration in the shader source and the client is expected to
infer the index from the declaration order.

This leads to some issues that are unique to each target language:

1. When targeting WGSL, this scheme is fragile if the shader source
   doesn't keep the index declarations contiguous. Any gaps in the
   indices will lead to incorrect results. This can happen due to a
   programmer error. This can also happen due to bindings that are
   unreachable by the entry point function, for example as a result
   of some refactoring.

2. When targeting MSL, the client needs to know the vello_shader's
   crate's internal binding re-assignment scheme and implement the
   same logic on their end to compute the indices. This stems from
   the fact that WGSL bindings *where indices are scoped to a
   bind group) and MSL bindings (where indices are scoped separately
   by resource type) get assigned from different ranges and
   numerically not the same.

To resolve this, the crate now exposes a list of indices alongside each
backend source.

Additionally, as a cleanup, this PR removes all unused bindings and
rearranges the binding indices to leave no gaps.

Resolves #330

[raphlinus]

This looks good to me. I'm curious to see how it will go for something with more complex bindings, like HLSL, but it seems reasonably straightforward so far.

[armansito]

This looks good to me. I'm curious to see how it will go for something with more complex bindings, like HLSL, but it seems reasonably straightforward so far.

HLSL is different but not drastically. Part of the idea with this change is that binding index representation is now separate for each backend language, so it's a (small) step towards supporting more of them. Not using multiple bind groups (thus descriptor sets/tables) definitely simplifies things for now.