XRGPUSubImage texture lifetimes

An issue was raised during a code review for my WIP prototype of the proposal today: We should decide on and tightly specify the lifetime of the textures returned in an XRGPUSubImage.

I think the general assumption is that the textures will be supplied by a swap chain of some sort on the backend that cycles through a number of textures as needed to keep the graphics pipeline flowing. There's also scenarios, though, where supplying a single texture could be sufficient, such as if the developers asks for a depth/stencil texture but the system does not make use of that data for reprojection or occlusion.

We would want those details to stay opaque to the developer, though, so they don't try to rely on a given behavior that may not be present on other devices. As such we may want to mandate that even if a texture is reused on the backend a new JS wrapper is returned each frame to prevent developers from trying anything funny. (This, of course, comes with some overhead.)

A more complex concern also crops up that wasn't present with WebGL: Command buffers can be pre-recorded and executed at a later point. This means that You could theoretically retrieve the textures for a layer, record (but not submit) render commands with them, allow the frame to finish, and then submit the recorded commands while the textures are presumably already in-flight to the compositor.

WebGPU handles this scenario with the canvas by introducing a concept of "expiring the current texture" where the texture is marked as destroyed once the frame ends but the "drawing buffer" for that texture is retained for use by the compositor. I imagine we will probably need a similar concept for the WebGPU bindings or even link directly to the WebGPU spec language in that regard.

CC @mwyrzykowski, @cabanier

Start with the XRGPUSubImage lifetime scenarios in the issue and the linked WebGPU “expiring the current texture” concept. Compare frame-end reuse, wrapper lifetime, and delayed command-buffer cases, then document an agreed lifetime rule in the binding specification. Done means backend texture reuse and frame validity are specified without exposing device-specific behavior.