QRhi renderpass load/store configurability brain dump

Some potential use cases have been brought up both from Qt Quick 3D and Qt 3D side that are not necessarily well-supported with the current model of having pre-defined load/store settings, with the only configurability being via QRhiTextureRenderTarget's PreserveColor and similar flags.

Think depth pre-pass in a separate renderpass (depth needs to be written out, cannot be DONT_CARE), or any special case when someone absolutely has to do an additional pass targeting the swapchain without clearing the content from the previous pass in the same frame.

We do not (and probably never will) support Vulkan subpasses (esp. since it has little applicability to other APIs), but rather some sort of configurability could be introduced via flags passed to beginPass() for instance. (but this would come with complications inside some backends, in particular, Vulkan)

There are some issues with this however, due to the graphics pipeline being dependent on the renderpass descriptor (in Vulkan at least). So just having plain flags for beginPass() is not sufficient. (that's why QRhiRenderPassDescriptor exists in the first place, but that's always created from a QRhiRenderTarget atm, not just out of nowhere)

For what it's worth, WebGPU (the high-level API that is closest to QRhi in spirit when it comes to vision and goals) seems to also follow a configure-on-renderpass-start approach (https://gpuweb.github.io/gpuweb/#ref-for-dictdef-gpurenderpassdescriptor ) (on the other hand I cannot seem to find where a GPURenderPipeline is associated with a GPURenderPassDescriptor - presumably it is left to the implementations to juggle with the native resources under the hood?)

However:

it is not clear we really want this. As long as one can record everything in one single pass (e.g. a simple depth pre-pass does not need to be a separate renderpass), the additional complexity that would be added here is basically not worth it.

For getting the depth buffer out of some renderpass - something that may be needed for Quick3D custom materials and effects - one can use a depthTexture in the QRhiTextureRenderTargetDescription instead of depthStencilBuffer, which will implicitly enable writing depth out.

Also, the way Qt Quick 3D integrates with Qt Quick in overlay/underlay mode is by definition incompatible with additional renderpasses on the main render target (the swapchain for the window) (in the 'render' phase, that is, one could do anything in the 'prepare' phase of course, but that's all cleared away when Qt Quick scenegraph issues the main beginPass()). Therefore relying on multiple renderpasses onto the main target is out question, so not sure if there is a use case for having non-default attachment load/store settings.

Needs some more thinking.