Feature detection for new core API capabilities #6337

We don't have a design pattern for feature detection of new core API capabilities.

This has come up recently:

• Multisampled array textures:
  Multisampled array textures: WGSL enable extension versus device feature #6283
  In this case, one option to just expose a WGSL language feature since there will be WGSL additions anyway (texture_multisampled_2d_array). That's what's currently proposed.
• Unaligned sizes on ASTC and ETC2 textures IF we make that core (EDIT: looks like we won't):
  Add texture-compression-unaligned feature to relax texture size block alignment requirement. #6312 (comment)
  In this case, a WGSL language feature is not an option.
• EDIT: See also Tracking issue: feature detection for new API changes #5484

IMO we should just expose these as device features that are enabled automatically. That is:

• If the browser has it, it'll appear in GPUAdapter.features.
• You can request it, but regardless of whether you do, you will always get a device that has it (at least if you have a Core-defaulting adapter). Similar to "core-features-and-limits" today.

This is the pattern that we'll necessarily use in the future if we move any currently-optional feature to be required by core, because we have to keep the existing feature name but will want to turn it on automatically.

Another option would be to just add something like navigator.gpu.apiFeatures however this would only really make sense for things that are in both core and compat, which is not usually the case.