livesim: Directly render from GPU data instead of round-tripping

[HadrienG2]

By virtue of being implemented using the same API as GPU-based compute backends, livesim can apply certain optimizations when running with those backends. Of those, API context sharing has already been implemented, but we're missing a fast data path when we directly use the GPU images produced by the GPU simulation instead of downloading their data to host memory then uploading it to VRAM again.

Implementation plan :

• In data::concentration, modify Species and Evolving to handle N+1 versions of the concentration, with round robin flipping. Use this in livesim to ask for 3+1 versions of the concentration.
• Split the livesim::pipeline code into a part that stays the same and a part that is specific to running with a buffer input. Call the latter livesim::pipeline::buffer, disable it in GPU rendering mode.
• Add a new livesim::pipeline::image module, enabled in GPU rendering mode, which implements a rendering pipeline based on a storage image. Share shader code using the same include trick as the compute_gpu backends, except this time we're sharing most of the main function and it's only the input access that's pipeline-specific.
• In livesim::input, comment out the upload code and change the Input typedef to Arc<StorageImage>.
• In livesim::frames, when running under a GPU backend, disable the entire notion of upload buffers and eager inout descriptor set allocation. Instead, prepare a descriptor set cache that will be lazily initialized for each observed (Input, SwapchainImage) combination. Flush the cache anytime the swapchain is recreated. In GPU mode, the rendering callback will only take an inout descriptor set, but Frames::process_frame will take an additional Species parameter. Further, can now avoid eagerly awaiting futures.
• In the main module, use a GPU-optimized rendering code path in GPU mode.
• Test, and hopefully observe better rendering performance.