Expose underlying BindGroup in wrappers

[Gonkalbell]

I've made the field on BindGroup wrappers public, in case a user needs to access the underlying wgpu::BindGroup. I've also made wrappers derive all the traits a wgpu::BindGroup implements.

Underlying wgpu::BindGroups derive Hash so they can be used as keys in hashmaps, and Clone so their underlying handle can be safely cloned. With this PR, now the wrapper structs implement those traits as well.

Exposing the underlying wgpu::BindGroup would be useful for situations where a user wants to use the wrapper structs in most situations, but has other places in their code that use raw wgpu::BindGroup and which they don't want to or can't update. I'm not sure if it's a concern that a user might construct a wrapper with an incompatible wgpu::BindGroup.

[Swoorup]

I think this is fine, as we don't want to hide wgpu constructs anyway.
Should this be a named field instead however? I find using .0 odd and hard to grep for.

[Gonkalbell]

I think this is fine, as we don't want to hide wgpu constructs anyway. Should this be a named field instead however? I find using .0 odd and hard to grep for.

I considered that. In wgsl_to_wgpu, they have a fn to_inner function. I could understand doing that instead. Or implementing From and Into for wgpu::BindGroup

[Swoorup]

I think this is fine, as we don't want to hide wgpu constructs anyway. Should this be a named field instead however? I find using .0 odd and hard to grep for.

I considered that. In wgsl_to_wgpu, they have a fn to_inner function. I could understand doing that instead. Or implementing From and Into for wgpu::BindGroup

That's fine. Will accept either approach 👍