Express GPU texture formats directly via a CPUBuffer GpuFormat field

[alsepkow]

Problem

Today, special texture formats are folded into the DataFormat enum (e.g. DataFormat::Depth32) and the GPU Format is inferred from DataFormat + Channels via toFormat(). This has two drawbacks:

1. Doesn't scale — every new special format requires extending DataFormat.
2. Can't express depth-stencil formats — D32FloatS8Uint's stencil component is a separate uint8, not a second channel, so it is not representable as DataFormat + Channels.

DataFormat and the GPU Format are really two different axes:

• DataFormat (e.g. Float32) — how to interpret the CPU bytes.
• GPU Format (e.g. D32Float) — the GPU resource format.

Proposal

Add an optional GpuFormat field to CPUBuffer that names a GPU Format directly, bypassing the DataFormat -> Format round-trip, and remove the special-cased DataFormat::Depth32. Backends can then just check isDepth on the format rather than special-casing an enum value.

# Before
- Name: DepthTex
  Format: Depth32

# After
- Name: DepthTex
  Format: Float32        # how to read the CPU bytes
  GpuFormat: D32Float    # explicit GPU resource format

This is cleaner and extensible to any future GPU format, including depth-stencil formats like D32FloatS8Uint.

Credit

Based on review feedback from @manon-traverse on #1229, who suggested using the Format enum directly in the YAML and checking isDepth instead of converting, to support depth formats that include a stencil buffer.