Fix #134259: Compositor crash when passes are used

In certain setups where passes are used in the viewport compositor,
blender will crash. This happens because passes may not be available
when the compositor first run but then become available in later runs.
Possibly because EEVEE is still compiling shaders. This is problematic
for the compositor because it caches the result of node tree compilation
for the specific data available, like passes, and the compositor does
not get informed when data becomes available like in the case of EEVEE
to invalidate the cached node tree compilation result.

Caching of node tree compilation was always a source of bugs but we
managed to workaround them in the past, so before we work on a fix for
this crash, we first evaluate the removal of caching to see if we can
live without it. Especially since a fix will be rather involved for the
release branch at this stage.

The time it takes to compile the node tree is:

- Small Tree (~10 nodes): 0.3ms.
- Medium Tree (~50 nodes): 0.6ms.
- Huge Tree (~300 nodes): 3ms.

The difference is not noticeable to the eye, probably since as the tree
becomes bigger, the evaluation time becomes more dominant, and small
trees are fast to compile.

It should be noted that we intended to remove caching in the future to
support things like lazy evaluation of node inputs, but we though a few
optimization needs to be done on the GPUMaterial compiler side to make
compilation faster, since it is the main bottleneck during compilation.

So considering this, I think it is acceptable to disable caching of node
tree compilations for the time being. I intend to optimize it such that
it always becomes less than 1ms, but we will have to delay that to 4.5.

Pull Request: https://projects.blender.org/blender/blender/pulls/134394

source/blender/draw/engines/compositor/compositor_engine.cc

@@ -241,6 +241,10 @@ class Engine {
   void draw()
   {
     update_compositing_region_size();
+    /* We temporally disable caching of node tree compilation by always resting the evaluator for
+     * now. See pull request #134394 for more information. TODO: This should be cleaned up in the
+     * future. */
+    evaluator_.reset();
     evaluator_.evaluate();
   }