Direct3D 12: Enhance management of texture data life cycle

[RandomShaper]

1. When available, graphics memory is asked not to be zero-initialized.

   That brings better performance since in most cases those bytes will be overwritten anyway.

2. Texture memory initialization is tracked across the limbo, garbage and done states.

- Limbo: resource just allocated, contents are dangerous unless overwritten by certain operations (like a clear), or discarded.
- Garbage: the memory has been discarded (i.e., D3D12 knows it has to ignore previous contents), but it's still not guaranteed to be black, orthogonally to the non-zero-mem feature.
- Done: the texture has known contents, either because it was updated with some image data or because it was cleared, worst case by this code, to black, to ensure garbage data is never used.

UPDATE: Approach simplified. It turns out that texture with many many subresources would add a lot of strain.

2. Texture memory initialization is guaranteed by clearing in black every texture that can be a UAV or RTV.

[akien-mga]

Needs a rebase, and a re-review.

[RandomShaper]

Rebased!

[DarioSamo]

PR currently does not handle D3D12_SRV_DIMENSION_TEXTURECUBEARRAY in _make_rtv_for_texture, so it crashes in dev mode with the following call stack due to the assert.

I could reproduce this on the 3D Platformer project, probably due to the use of reflection probes.

[DarioSamo]

After fixing the error I mentioned above at least everything seems to still work, but the behavior regarding the excessive amount of clears likely needs to be reviewed, as the comment indicates it shouldn't happen often but it triggers often enough to go above the default limit.

[DarioSamo]

Approved. The new approach to clearing the textures seems a lot cleaner and also requires far less tracking that can hurt performance.

[akien-mga]

Thanks!