Quick3D: Shader managment rework to enable an efficient QRhi-based port

Direct OpenGL usage is to be removed in Qt 6.0 and is replaced by rendering via the Qt Rendering Hardware Interface and the associated graphics and compute shader management machinery provided by the Qt Shader Tools module.

See https://github.com/alpqr/talks/blob/master/Qt_World_Summit_2019/qt_graphics_qtws2019.pdf

This affects Quick 3D and involves significant rework in both the lower level rendering layer and the shader management system for default and custom materials. This task is about the latter.

Quick 3D should make it possible to move away from runtime shader string generation and compilation. This is needed to enable better performance, and to avoid possible problems (support for less-common platforms, licensing, etc.) due to relying on the Qt Shader Tools module and its 3rd party dependencies.

• For a given scene, we need to be able to generate all shader code (both for default and custom materials used anywhere in the scene) offline. This means outputting a set of files with GLSL source in them.

• Preferably by having both a library and a command line tool, in order to allow future integration into the designer tools.

• The resulting shader sources are then run through the compiling and processing steps by the Qt Shader Tools module. In the first phase this may simply mean manually running qsb, and so no work is needed for this step in this task.

• The engine should have some hooks to find the set of .qsb files associated with the scene at run time. The actual usage of them is not part of the task as that is to be implemented in the initial port onto the RHI.

• The library and command line tool must be able to handle additional options that specify additional variants to generate. For example, if a scene contains 2 lights (as in Light nodes), a default material variant with 2 lights should be generated. However, if the options specify to support 3 and 4 lights as well, the output should be variants for 2, 3, and 4 lights. This is because dynamic changes to the scene (say, a dynamically instantiated Light node) cannot be deduced by just parsing the QML code. Eventually this is expected to be exposed visually in the designer tools "baking" settings, or similar.

• It is yet to be seen if/how runtime shader compilation and processing is supported in Qt 6. It could be that an initial QRhi port will be brought up using that approach, but that does not mean we want to support that in production. Therefore, the offline (or application build time) processing should be the default approach. This means potential consequences for the designer and deployment story. Deploying single QML files is likely not an option in Qt 6 time frame anymore, without appropriate asset baking steps. This is to be managed in future, separate tasks.