Intermediate render target management & recreation

## Problem

Currently, intermediate render targets (such as those used in post-processing effects) need to be manually recreated along with the relevant bind groups any time the display resolution changes. To manage the targets and bind groups, I have been doing the following:

1. Store the textures in the `TextureCache`.
2. Each frame, query the window size, optionally scaling it for each texture.
3. Save the `TextureId` of the existing target, then look up the texture in the cache using the queried size.
4. If the returned `CachedTexture` has a different `TextureId`, recreate any bind groups that contain it.

This results in substantial boilerplate and is unwieldy when working with numerous intermediate targets. It's also not clear where these targets should live: are they resources updated by a system, or should they live in a particular `Node` and be recreated with `Node::update()`?

## Potential solutions

1. **Don't change anything**

Rather than making any API changes, come up with a convention for managing these targets and document it somewhere.

2. **Some sort of special texture cache**

A specialized version of `TextureCache` could respond to changes in display resolution by recreating the relevant textures. Unfortunately, this doesn't solve the bind group problem. Additional information could be introduced to allow automatic bind group recreation, but this would duplicate information that is already present elsewhere in the renderer.

3. **On-demand render target pool**

Rather than creating a series of dedicated targets for a particular rendering task, the renderer could maintain a pool of general-use targets to be acquired on-demand for a particular render pass. This allows all targets to be recreated at once. However, bind groups would need to be created at the time when the target was acquired -- likely interrupting drawing -- rather than in advance. This seems likely to have negative performance implications for render graph execution.

4. **Update targets using the render graph**

Other render graphs such as [Granite](https://github.com/Themaister/Granite)'s allow render targets to be specified with either an absolute size or a size relative to some node input and then automatically assigned from a pool. This would require a preprocessing step on the graph in order to select a concrete size for each target and recreate it if needed. It's the most invasive of these solutions, as it modifies both the render graph's public API and its internals. On the other hand, it solves the problems with option 3 by allowing bind groups to be regenerated ahead of time instead of interrupting draw calls.

Start by reading the TextureCache, Node::update(), bind-group handling, and render-graph concepts referenced in the issue. Compare the four proposed directions and establish which API and ownership model should manage resolution-dependent render targets; done means an agreed approach that addresses both target recreation and dependent bind groups.

Written by the indexing model from the issue text.