Fix non-srgb RenderTarget::Image

[beicause]

Objective

Fixes #22031 (comment). Fixes #15201.
#22031 makes ViewTarget::out_texture_format to return the underlying texture’s format, which causes some issues:

1. ExtractedWindow::swap_chain_texture_view always uses srgb view. But the underlying swap chain texture in WebGPU can be Bgra8unorm, leading to format mismatch between the render pipeline and the render pass.
2. We can no longer use srgb view for non-srgb target texture, it will panic due to incompatible pipeline:

 let mut image = Image::new_target_texture(512, 512, TextureFormat::Rgba8Unorm); image.texture_view_descriptor = Some(bevy_render::render_resource::TextureViewDescriptor { format: Some(TextureFormat::Rgba8UnormSrgb), ..Default::default() }); image.texture_descriptor.view_formats = &[TextureFormat::Rgba8UnormSrgb];

Solution

Reverts #22031.
Renames some format to view_format explicitly.
Adds view_format to GpuImage and Image::new_target_texture so we can make render pipeline match render pass texture view.

Testing

Tested render_to_texture and screenshot examples on linux and webgpu.

The rendered Rgba8Unorm texture with or without srgb view in MeshMaterial3d looks the same, but the underlaying data is different:

With srgb view:

Without srgb view:

[alice-i-cecile]

@bonsairobo, can you take a look please?

[bonsairobo]

Sorry! I didn't realize that webgpu still isn't the default for wasm32 targets, so I must've only tested a WebGL2 build.

I would prefer if the revert happened in its own PR, but idk if there is any precedent for that in Bevy.

I'll review the 2nd commit.

[mockersf]

Yup, it's nicer for the git history to do revert as stand alone PRs as we squash PRs on merge

[bonsairobo]

LGTM

[beicause]

Ok, I've opened a PR for reverting.