API Issue for Renderer

[DasLixou]

See original discussion on zulip here

The current API which can be seen in the examples suggests that there should be one Renderer per wgpu::Device.
This can be a problem when you have one gpu which supports and must handle multiple surface formats, which can happen when having multiple windows on multiple monitors of different formats (i think).
Because I don't have multiple monitors, I helped a bit in code with this patch on the with_winit example:
force_different_surface_format.patch
I saw that my window expects Rgba8Unorm and forced it to use Bgra8Unorm.
After running, the program crashes with the following error:

Rgba8Unorm
Initialising in parallel using 6 threads
Parsed svg Ghostscript_Tiger in 18.0366ms
Encoded svg Ghostscript_Tiger in 3.6642ms
[2024-04-06T11:03:40.934Z ERROR wgpu::backend::wgpu_core] Handling wgpu errors as fatal by default
thread 'main' panicked at C:\Users\lixou\.cargo\registry\src\index.crates.io-6f17d22bba15001f\wgpu-0.19.3\src\backend\wgpu_core.rs:3006:5:
wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 2, Vulkan)>`
    In a set_pipeline command
      note: render pipeline = `<RenderPipeline-(0, 1, Vulkan)>`
    Render pipeline targets are incompatible with render pass
    Incompatible color attachments at indices [0]: the RenderPass uses textures with formats [Some(Rgba8Unorm)] but the RenderPipeline uses attachments with formats [Some(Bgra8Unorm)]


note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\with_winit_bin.exe` (exit code: 101)

From conversation on zulip linked at the top, the idea of removing the manual Vec<Option<Renderer>> list and moving it into the RenderContext to hide the selection of a renderer to the end user came up.
It is open to debate whether we want multiple renderers over one device, which needs us to change the basic Vec<Option<_>> solution, or supplying the surface format on render command (Daniel thinks that the surface format is only needed for the blit pipeline), or something not mentioned here.

Another interesting think is what happens when a window gets created with one surface_format and then gets moved to another monitor which is HDR (I am not sure what the OS does there and if we need to dynamically change the surface_format, what is when it is split up between two monitors? Would be great to know if there are any OS Resources documenting that).