Add COPY_SRC to Metal's surface usage bits.

[Toqozz]

Description
On machines running Metal, we could not configure surfaces with the COPY_SRC usage flag. This flag is used a pretty often on platforms that do support it, and often you'll have macOS users submitting a bug to the root project, which requires them to implement a backbuffer or some other workaround.

See "Discussion".

Testing
The simplest way to test is to add a wgpu::TextureUsages::COPY_SRC usage flag to hello_triangle example's surface configuration. Prior to this change (and given you're on macOS), you'll get a panic Error in Surface::configure: requested usage is not supported. This change fixes the panic.

Discussion
I can't find anything that says why this shouldn't be/isn't possible. I've tested the change on an M1 Pro Macbook which works without any issues, and I've even run it with Metal API validation enabled -- no errors. I found this pull request from Feb 2022, which added the COPY_DST flag with similar concerns, but no real answers.

From reading the Metal documentation (I'm a novice, to be clear), it seems that the flag that really matters is isFrameBufferOnly, which we already set appropriately depending on whether the texture usage is only RENDER_ATTACHMENT.

Textures obtained from a CAMetalDrawable object may only be usable as attachments, depending on the value of framebufferOnly passed to their parent CAMetalLayer object. Textures created directly by the app do not have such restrictions.
https://developer.apple.com/documentation/metal/mtltexture/1515749-isframebufferonly

https://developer.apple.com/documentation/metal/onscreen_presentation/reading_pixel_data_from_a_drawable_texture

So everything seems fine. We could probably allow more flags, but this at least brings things in line with DX12.

[Wumpf]

Thanks for the fix!
Digged around a tiny bit as well and also couldn't find any reason why the texture shouldn't be copyable.

Could you please add a brief changelog line about this bugfix?

[Toqozz]

Sure thing.