FusionOptimizer truncation logic should be backend specific

[ricardoV94]

Description

The Composite checks if scalar Ops have a C implementation before attempting to fuse them. This does not make sense for non-C backends. For Numba we might want to check if the Scalar Ops have a non-object implementation (if that even matters?).

There are also some issues revealed by #121, resulting from interactions between Python and C backends (the Python implementation is restricted to 32 operands), and a lack of clear information at the rewrite level about which one will be ultimately used.

We have the cxx flag and mode=FAST_COMPILE, both of which prevent the use of the C backend, but the rewrite has no way of knowing the latter for example. In #121 I considered at one point creating 3 versions of the rewrite, one for pure-python, C, and Numba, and registering the last two with cxx_only, numba_only. However there is no py_only, and the Elemwise perform method will try really hard to use the C code, meaning the py_only FusionOptimizer would always have to consider which scalar Ops have C code.

This is just an ugly symptom of the degree to which the C code is intertwined with the graph logic of PyTensor...

Solutions

1. Restrict the fusion optimizer to cxx_only and numba_only. The Python method may now be used when calling FAST_RUN or otherwise explicitly including fusion. However, it's never going to FAST_RUN in Python anyway and the latter is actually dangerous. Some tests would need to be tweaked.