Defer set_immediates to draw/dispatch call time

[beicause]

Connections
Depends on #9569

Helps with #8556
Fixes #850

Description
Fixes #850 by defering set_immediates to draw/dispatch call time

When executing SetImmediate command, we record the data and mark it as dirty, and then actually push the immediates to the GPU at draw/dispatch time.

Encoding render bundles is similar, we conditionally push SetImmediate command only before encoding draw/dispatch commands. Because of this values_offset has been removed. Instead we store each immediates in a Vec inside SetImmediate. I also considered using SmallVec, but it would increase the size of all commands and I'm not sure if it's worth it.

The above logic is applied in wgpu-core. Alternative would be applying it in wgpu-hal.

Testing
With this PR and gpuweb/cts#4646 most cts will pass:

cargo xtask cts 'webgpu:api,operation,command_buffer,programmable,immediate:*'
cargo xtask cts 'webgpu:api,validation,encoding,cmds,setImmediates:*'
cargo xtask cts 'webgpu:api,validation,encoding,programmable,pipeline_immediate:*'
cargo xtask cts 'webgpu:api,validation,pipeline,immediates:*'

I also added wgpu-validation tests for render and render bundle. It's not necessary, but it doesn't hurt either.

Squash or Rebase?
Squash

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.