Implement high level resource dependency graph in rendergraph

[IAmNotHanni]

Is your feature request related to a problem?

Currently, rendergraph has only limited knowledge of how all resources of rendering are used really.
For example, a buffer might be read inside of a graphics pass, but rendergraph might not know about this in all cases.
To implement a high level overview of all rendering resources for rendergraph, I propose the use of so called rendermodules.

Description

As can be already seen in the folder structure of the code, we have render modules. Currently only octree and imgui are rendermodules. The idea is the following: abstract render modules further by introducing a RenderModule class. Each rendermodule is registered to rendergraph. Each rendermodule can have an arbitrary number of graphics passes or other resources. With this, rendergraph finally knows which resources are associated with what render modules. To enforce this link between resources, we let the builder patterns (like GraphicsPipelineBuilder) know about the current render module that is used while creating a pipeline. Each builder which is related to rendergraph stores a handle to rendergraph internally, and when a new object is built, it is registered automatically to rendergraph through the builder in the context of the render module which is currently in use. This way, rendergraph gains high level knowledge over which resources are used by what rendermodule. The same will be applied to GraphicsPassBuilder, for example.

Alternatives

Keep everything as it is, which prevents us from developing rendergraph much further.

Affected Code

rendergraph

Operating System

all

Additional Context

none

[IAmNotHanni]

Another advantage of splitting the renderer conveptually into rendermodules would be synchronization: For each frame in flight, the data of each rendermodule must be externally synchronized. Maybe we can enforce this by using a std::mutex on a per-rendermodule basis? This synchronization requirement is not clear in current rendergraph2.