Allow Image to retain shared immutable pixel storage

[KaiStarkk]

Bevy’s Image currently stores CPU-side pixel data as Option<Vec<u8>>. This works well for decoded and procedurally generated images, but requires an additional allocation and copy when an asset loader already owns immutable image data in a suitable layout.

We are working on a game that stores precompiled, GPU-ready texture payloads in read-only mmap-backed rkyv archives. These payloads can be represented as zero-copy bytes::Bytes subranges whose owner retains the mapping. wgpu only requires an immutable byte slice during upload, but converting that slice into Vec<u8> duplicates the complete texture immediately before the GPU transfer.

A suitable storage abstraction could support both existing mutable images and shared immutable data:

#[derive(Clone, Debug)]
pub enum ImageData {
    Owned(Vec<u8>),
    Shared(bytes::Bytes),
}

Image could expose storage through methods rather than its container:

impl Image {
    pub fn data(&self) -> Option<&[u8]>;

    /// Returns mutable pixel storage, copying shared data into owned
    /// storage on its first mutation.
    pub fn data_mut(&mut self) -> Option<&mut [u8]>;
}

Existing decoders, procedural images, render readbacks, and frequently modified images would continue using Owned. Asset loaders could construct Shared data from static storage, shared buffers, mmap owners, or zero-copy subranges.

The intended semantics would be:

• Reading either representation returns &[u8].
• Cloning Owned retains the current deep-copy behavior.
• Cloning Shared shares the underlying immutable storage.
• Requesting mutable access to Shared performs one explicit copy and replaces it with Owned.
• Subsequent mutation uses the owned allocation directly.
• None continues to represent an image without CPU initialization data.
• GPU preparation passes the resulting slice to the existing wgpu upload path.

This removes unnecessary source-buffer-to-Vec copies while preserving Bevy’s mutable-image behavior. It doesn't attempt to avoid the required CPU-to-GPU transfer or introduce a separate rendering path naturally.

As to how loaders would create shared storage:

pub fn set_shared_data(&mut self, data: bytes::Bytes);

Alternatively, ImageData could remain public while the containing Image field becomes private.

PR #18751 previously explored using Bytes as the sole backing storage for Image. Retaining distinct owned and shared representations addresses the mutable-access difficulty that arises from a complete replacement. Encapsulating the representation also aligns with #11888’s proposal to protect Image’s layout invariants behind constructors and accessors.

Keen to hear others' thoughts.