https://github.com/numba/numba/issues/10356

Also simplified test. Shared variables aren't needed for the test and clobber it

Unlike MIT-SOT and SIT-SOT these can be positive or negative, depending on the order of differentiation

Workaround for: https://github.com/numba/numba/issues/9554

This helper could arbitrarily override the default output_type from `ScalarOp.make_node` so that the output type matched one of the input types.
This can be used to create artificial Op signatures that don't make sense or can't be cleanly implemented in other backends. For instance an Add with signature (int8,int64)->int8.

This helper was historically used in:
 1. Elemwise inplace rewrite. I assume as a preventive measure. However, regular use should never require changing the ScalarOp signature, as we only try to inplace on inputs that match the output dtype and recreating the same Op with the same input types should always return the same output type. ScalarOp don't have a concept of inplace, only the Elemwise wrapper does, and it shouldn't require recreating/mutating the original Op.
 2. SecondOp. Here it makes sense, but a custom static_method works just as well
 3. Inplace tests with the inplace variants of `@scalar_elemwise` decorator. These test Classes were removed. It still didn't make sense to test/force Ops to have an artifical signature for the sake of tests. They were removed anyway

Note: Numba object mode fallback is not safe with lists

Closes https://github.com/pymc-devs/pytensor/issues/1245