Wgpu: Defaults in the builder

[kvark]

Is your feature request related to a problem? Please describe.
Following #851 and trying to use it, I feel like we should reduce the new() parameter lists. The more stuff it has, the more awkward it feels to use the builder patter after it.

Describe the solution you'd like
Perhaps, we should change the default field guidelines from the current "everything that doesn't have a usable default" to "everything that doesn't have an obvious default". The difference is subtle but important, can be demonstrated on the "usage" flags: currently we pass it into the new(), since it's required, but instead we could initialize it to empty flag set and have a setter for it. In this example BufferUsage::empty() is not a valid default, but it's an obvious one, so there is no ambiguity or broken expectations.

Subject fields:

• usage: default to `empty()
• extent: perhaps we should initialize it to (1,1,1)?
• size: does it need a default of 0?
• arrays of stuff: we could initialize to a default Cow, whatever it does

Describe alternatives you've considered
Keep the current way of things.

Additional context
We may want to address this before updating the wgpu-rs examples (cc @Andful ) to avoid doing extra work, as long as the agreement is reached.

[grovesNL]

It would be nice to match the defaults of the WebGPU specification for these types so we don't have to come up with different sets of defaults, even if it means all required parameters are passed into new for builders.

This discussion makes me reconsider whether the extra effort of builders to be able to expose Cow/IntoCow in the public API of wgpu-rs is worthwhile though (compared to plain structs like we had before Cow). For example, reading the type signatures of https://wgpu.rs/doc/wgpu/struct.BindGroupLayoutDescriptor.html#impl reminds me of the concerns people had about nalgebra's documentation due to heavy use of traits and generics (eventually being partially resolved with nalgebra-glm), so I'm a little concerned this will scare new users away. Even though Cow provides some benefits I'm not sure the pros outweigh the cons.

[cwfitzgerald]

I think that this route is the correct way to go, though I do have a minor concern.

Right now, with full direct construction, we force the user to make a decision about every single field, reducing the likeliness of filling out a struct incorrectly by missing a field. When using a builder they might end up with one of these "unusable default" defaulted.

I think it might be worthwhile to validate we aren't passed these unusable values, possibly with a (public?) member function on the descriptor.

[kvark]

Builders are gone, problem solved