FusionOptimizer truncation logic should be backend specific

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.

Start by tracing FusionOptimizer, Composite, and the Elemwise perform method, then compare how cxx, FAST_COMPILE, FAST_RUN, and fusion affect backend selection. Review issue #121 and determine how fusion should distinguish Python, C, and Numba implementations; done means the rewrite applies backend-appropriate truncation without the reported cross-backend inconsistencies.