Hardware feature levels in WGPURequestAdapterOptions

[kainino0x]

I have posted a proposal for the JS API here:
gpuweb/gpuweb#4656

I would like to do the same thing in the C API, except (at least as an initial proposal) with one major difference: we require a feature level in WGPURequestAdapterOptions instead of defaulting to "FL1"/"Core".

[kainino0x]

May 9 meeting:

• Kai’s proposal for C API: same but require minFeatureLevel (it has no default, for now)
• …
• CF: Feels like “compat” is now the actual baseline…
• KN: Compat by default?
• CF: As long as we have features to reach back up to core
• …
• AE: Branching feature levels? “modern mobile”/”modern desktop”. Should be OK, you can be upgraded along the same path
  • Features that will be in mobile but not desktop? ASTC, tile local storage?
• CF: Between defaulting to compat and requiring a feature level request, don’t think I care.
• AE: D3D allows you to request a list of feature levels.
  • CF: Weird D3D11ism, like Win7 doesn’t know what FL11_1 is, you have to try twice.
• KN: will bring this proposal to the WG and we can talk about it again after it’s had some discussion there

[kainino0x]

One point someone on our team raised about having webgpu.h default to compat, is that compat does enable a bunch of extra validation some of which is not trivial (for example the validation that one texture is only used with one sampler).

[kainino0x]

Closing in favor of #412 which tracks just the one remaining question here.