Destroy image textures before dropping them

[timon-schelling]

Running vello in Firefox, textures seem to never get freed (not 100% sure, but
it might be SpiderMonkey's GC never feeling GPU memory pressure). Chromium
behaves better, but still seems to have the same general issue of GCing
textures too late.

For our other wgpu textures in Graphite we manually call destroy() to free as fast as
possible.

That leaves the textures from vello as the remaining "leak" that we can't control.
This PR contains the minimal workaround that could be done in vello (works for us at least).

One could also address the TODO and implement a texture pool in the same PR.
I can do that if desired.

[raphlinus]

We discussed this in Renderer Office Hours. It makes sense, and thanks. During the call I was unsure if this was safe; it wouldn't be in Vulkan to destroy an image while there was work referencing it in flight, but WebGPU does make this safe.

[DJMcNab]

One thing I am concerned about is the possibility that this is not the only place that we use these items. That is, I'm worried there's a chance that a different clone of this texture exists - have you convinced yourself that isn't the case?

(But @timon-schelling, let us know when you want us to merge this - it's reasonably low risk.)

[timon-schelling]

In Graphite we use a texture wrapper type that is not clone (inside arc in most places) and calls destroy on drop, that makes it a little safer. Also works well with a texture pool.

I think Graphite is one of the heavier users and we basically run into all vello issues (like things that can be caused by this) at some point.
And I would feel responsible creating follow-up PRs if this causes an issue.

Thanks for considering

[DJMcNab]

Just to note, this PR is now in the state of unclear responsibility for the next step. If you're confident that this is correct, then I'm happy enough to land this based on that. But your latest message doesn't explicitly answer that question, so I just want to make sure that is the current state.

But I am worried by this change just because I don't think the failure mode will be obvious - it would be a failure at an arbitrary later point that the texture is destroyed. I'm not sure if the stack trace would be especially enlightening, or just a generic 'wgpu default error handler' message.

[timon-schelling]

Yes I'm confident this is the correct change.

I thought the question was for the other maintainer, sorry for the confusion.
Just wanted to assure that I would feel responsible for noticing and fixing things if this causes issues in the future.

[sagudev]

Running vello in Firefox, textures seem to never get freed (not 100% sure, but it might be SpiderMonkey's GC never feeling GPU memory pressure).

Yes, right now FF does not report "Associated Memory" to the SM.