API Issue for `Renderer`

Nobody has claimed this yet.

> See original discussion on zulip [here](https://xi.zulipchat.com/#narrow/stream/197075-gpu/topic/Better.20.60Vec.3CRendererer.3E.60.20api)

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](https://github.com/linebender/vello/files/14893333/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 = ``
In a set_pipeline command
note: render pipeline = ``
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>` 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>` 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).

Start with the `with_winit` example and the `Renderer`/`RenderContext` API discussed in the linked Zulip thread. Compare the current per-`wgpu::Device` renderer selection with the proposed `Vec>` move, including surface-format changes and HDR monitor cases. Done requires an agreed API design that avoids incompatible render-pass and pipeline formats.

Written by the indexing model from the issue text.