Properly deal with over-aligned T's in dynamic buffers

[cwfitzgerald]

This PR allows two different use cases (1 is arguably a bug).

1. It is theoretically possible that the default alignment for https://docs.rs/wgpu/latest/wgpu/struct.Limits.html#structfield.min_storage_buffer_offset_alignment is lower than the most-aligned structure DVec4.
2. This lets you use the dynamic storage buffer api to build dynamically defined structures. You can set the designed alignment to 1, then you can use each "element" in the dynamic storage buffer as a member of a different type and it will automatically lay things out correctly.

[teoxoy]

Regarding the first issue, the WG decided to require implementations to provide a dynamic offset limit that's min 32 (alignment of vec4<f64>) in gpuweb/gpuweb#3002. While a larger alignment could be specified in the shader (for struct fields which in turn increase the alignment of the struct), it seems this is irrelevant since this kind of alignment is not enforced by the hardware (see gpuweb/gpuweb#2999 (comment)).

Is the 2nd use case aimed at providing a way to lay out structs with fields that are unknowable at compile time?

I think it might be worth panicking on an alignment that's less than 32 to better comply with the spec instead and provide some other way to achieve the 2nd use case.

What do you think?

[cwfitzgerald]

the WG decided to require implementations to provide a dynamic offset limit that's min 32

Ahh, didn't realize that, makes sense.

Is the 2nd use case aimed at providing a way to lay out structs with fields that are unknowable at compile time?

Yeah - we have user defined shader inputs that we read and need to properly lay out. I have no particular cares about how we get there :) The reason I reached for the DynamicUniformBuffer is that the code was already there to do basically what I needed to do, just needed this extra alignment requirement. Do you have any thoughts on how this could be achieved?