Add Limits::max_buffers_and_acceleration_structures_per_shader_stage

[teoxoy]

Connections
Fixes #9287.

Description
Adds a new combined limit for all buffer types (storage, uniform, vertex buffers, and acceleration structures) that share Metal's buffer argument table. On Metal without InstanceFlags::STRICT_WEBGPU_COMPLIANCE set, the new limit and the individual per-type limits (max_storage_buffers_per_shader_stage, max_uniform_buffers_per_shader_stage, max_vertex_buffers, max_acceleration_structures_per_shader_stage) are set to 29. If InstanceFlags::STRICT_WEBGPU_COMPLIANCE is set, max_buffers_and_acceleration_structures_per_shader_stage is set to u32::MAX, so the behavior is the same as without this PR.

Testing
Added new tests.

Squash or Rebase?
n/a

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[teoxoy]

I'm not sure why but llvmpipe doesn't say it has VK_KHR_swapchain_mutable_format but according to vulkaninfo reports it should be available.

Presence of VK_KHR_swapchain_mutable_format is what sets DownlevelFlags::SURFACE_VIEW_FORMATS. Because it's not available and we now set InstanceFlags::STRICT_WEBGPU_COMPLIANCE for CTS, the CTS can't find any adapters...

[teoxoy]

The workflow that builds llvmpipe sets platforms to an empty string so none of the defines that would enable the extension are set (ref). This is probably on purpose since CI is headless? Idk if you can still get swapchains on headless.
cc @cwfitzgerald

Given that DownlevelFlags::SURFACE_VIEW_FORMATS has to do with WSI I think we should mark it as not necessary to consider the adapter WebGPU compliant.

[cwfitzgerald]

.This is probably on purpose since CI is headless? Idk if you can still get swapchains on headless.

Yeah I don't think you can. We should change that check so that if no swapchain extensions are available, we shouldn't gate that downlevel flag on it.

[cwfitzgerald]

I'm not sure we should change the definition of compliant - as users will expect surface_view_format support on a compliant adapter - what I meant is to only gate SURFACE_VIEW_FORMAT on VK_KHR_swapchain_mutable_format if there's a surface extension available, if there isn't, unconditionally expose it.

[teoxoy]

I changed the last commit and based it off VK_KHR_swapchain so we don't need to check each individual platform extension. Something I noticed though:

wgpu/wgpu-hal/src/vulkan/adapter.rs

Lines 2421 to 2423 in 47cce25

	if !unsupported_extensions.is_empty() {
	log::debug!("Missing extensions: {unsupported_extensions:?}");
	}

We just log unsupported but required features, that doesn't seem right at all. VK_KHR_swapchain was marked as always required so it confused me as to why we could create the device at all. I opened #9726 for this.