Tolerate destruction of textures used in immediate queue operations prior to submit

[andyleiserson]

Textures used in "immediate" operations on GPUQueue (e.g. writeTexture) must not be destroyed at the time that writeTexture is called, but it is okay to destroy the texture at any point after that. The actual commands effecting writeTexture will not be executed until the next submit, but my understanding is that that is our implementation detail.

This change checks at submit time whether the texture is held pending deletion and, if so, does not raise a destroyed resource error.

It's possible that any texture used in pending_writes must either be active or in the list for pending deletion, but I'm not sure if that's the case. If it is, we might want to do something like make the check here a debug-only assertion.

I've also included a separate commit that adds env_logger to cts_runner.

Testing
This may fix a large number of CTS tests, I haven't tried to identify them all, but I did add one set. I also added a directed test.

Squash or Rebase? Rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.