Reconcile post-processing effects and tonemapping

Currently we have "\note When using post-processing effects, the application-provided shaders usually expect linear color data without tonemapping applied. It is then essential to bypass the built-in tonemapping by setting tonemapMode to SceneEnvironment.TonemapModeNone." in the effect docs.

This is not ideal.

The presence of effects should automatically trigger not inserting the tonemapping stuff (or just not set the corresponding QSSG_ENABLE_xxxxx_TONEMAPPING defines) in the main pass. Instead, the tonemapping should be performed in the fragment shader for the last pass of the last effect in the chain, unless tonemapping is set to TonemapModeNone.

This makes the API logical (tonemapping is enabled or not, does not matter if there are post-processing effects present), and also keeps compatibility with the current recommendation of the Effect docs since setting None has the same effect as before (although that recommendation would get removed now with the more unified behavior).

The challenges lie in

• sending data and flags around to know when to, and when not to, do certain things. For example,  QQuick3DEffect::updateSpatialNode() needs to massage the fragment shader main() but only if certain conditions are true, how those are communicated from the SceneEnvironment f.ex. is not clear,

static const char *effect_fragment_main =
 // ### get QSSG_ENABLE_xxxxx_TONEMAPPING defined based on the scene.env.
 "#include \"tonemapping.glsllib\""
 "void main()\n"
"{\n" 
" qt_customMain();\n" 
" gl_FragColor = qt_tonemap(gl_FragColor); 
"}\n";

• a changed tonemap mode value should now lead to updating the effect nodes as well (how?), with the filename-based cache(s), in QSSGRhiEffectSystem for instance, having to take additional flags into account since the shader source code may be different even though the source .frag file is the same.