Add COPY_SRC to compositor surface

[maxbergmark]

I have been working on iced_glass, a widget library for iced that provides Liquid Glass-like effects in iced. To achieve these effects, it is essential to be able to read from the underlying background texture while rendering.

This PR enables the COPY_SRC texture usage for the rendering surface, if that usage is available on the current platform. This approach is non-intrusive, and should not be noticeable to anyone currently using iced. If the PR is accepted, the end user will be able to query the texture usages before rendering, to confirm that the COPY_SRC flag is active for the background texture.

I have tested this change myself, but I don't have the possibility to verify how this behaves on different machines or renderers that don't support COPY_SRC. If there is anything that I should change, or need to clarify, please let me know! This same change could also be done on the master branch, to enable COPY_SRC in iced 0.15.

Alternatives considered

Feature flag

Adding COPY_SRC could be hidden behind a feature flag. The main reason for not choosing this approach is that it adds complexity across the project, and hides a feature that could be enabled by default. A feature flag could also lead to confusion, if the underlying surface doesn't support COPY_SRC. In those cases, the end user would enable the feature, but get a runtime error when trying to copy the texture.

[maxbergmark]

After additional research into different render targets, and how wgpu handles surface capabilities for web (https://github.com/gfx-rs/wgpu/blob/82fdc4e5ca1297b94b297d4fda49fc01800504dd/wgpu/src/backend/webgpu.rs#L3940) I have come to the conclusion that the current state of this PR doesn't solve the underlying problem when compiling iced + iced_glass for web.

Due to the wgpu implementation for web targets, the COPY_SRC flag isn't included as an advertised usage, even if some browsers (e.g. Chrome and Firefox) support it. However, error handling isn't easy for browsers that don't support COPY_SRC. When testing an example scene in Safari, the entire screen renders as black, likely due to an error when copying the texture in the rendering pipeline.

I need to do some more research and experimentation to find out the best approach for handling both native applications and browser rendering. My hunch is that the only currently viable approach is to check the surface capabilities when compiling natively, and to always include COPY_SRC when compiling for WASM32, and hope for the best. Either that, or completely skip WASM32 for now.

[maxbergmark]

From my own testing, I can't get either iced_glass or the official "tour" example to render properly in Safari, but it works just fine in Chrome. Both render as completely black screens in Safari, but if there is any documentation for how iced works in different browsers I'd be happy to do another assessment. For now, this is my current implementation for how I handle surface usages:

let capabilities = surface.get_capabilities(&self.adapter);
let has_copy_src =
    capabilities.usages.contains(wgpu::TextureUsages::COPY_SRC);
// On WASM, COPY_SRC is never advertised, so we always include it.
// https://github.com/gfx-rs/wgpu/blob/72bb53b0ed9c49b49f71d738cfe3acc982ce7ab0/wgpu/src/backend/webgpu.rs#L3941
let usage = if has_copy_src || cfg!(target_arch = "wasm32") {
    wgpu::TextureUsages::RENDER_ATTACHMENT
        | wgpu::TextureUsages::COPY_SRC
} else {
    wgpu::TextureUsages::RENDER_ATTACHMENT
};

This change would only be needed if iced should support e.g. blurring effects in the browser. If that's not a prioritized feature, I'd go with the original contents in the PR.

[maxbergmark]

I have done some testing regarding browser compatibility for COPY_SRC, and it seems to be widely supported, as long as webgpu is being used. The only problematic browser that's been tested is Safari, which I've been able to track down to a bug in Webkit. I was able to find a workaround in iced for the Webkit bug related to the WebGPU standard., but I don't think that fix belongs in Iced. Rather, I'll try filing a bug report in Webkit and wait for a proper fix.

	Linux	MacOS	Windows	iOS	Android
Chromium	✅*	✅	✅	✅	✅
Firefox	✅*	✅	✅	✅	✅
Safari		❌		✅

*Depends on webgpu + vulkan support, or webgl fallback