Does `destroy_map` need to specify which output destroys which input?

Description

This seems focused on single output Ops. It's the application of the node that destroys the input, not the computation of a specific output. For instance, in LU_factor which outputs both LU, and p we artificially specify that destroy_map is {1: [0]}, because {0: [0], 1: [0]} is not allowed (we get a mulitple destroyers error when introducing the inplace during rewrites).

We should check if anything in the codebase relies on a strict map from input to output. If not, our Ops could simply have a tuple for destroy_map indicating which inputs are being destroied, and not a dict from outputs to inputs like we have now.

Some Ops may be overloading this functionality to know for instance which of multiple outputs in being computed inplace of an input (such as in Elemwise) but this is information that could be stored elsewhere.

Otherwise, if this mapping is actually needed for something, we may need to extend the inplace consistency check to at least allow multiple outputs from the same node to destroy the same input.

Start by tracing destroy_map usage and the inplace consistency check, then compare the LU_factor and Elemwise cases described in the issue. Determine whether any code relies on a strict output-to-input mapping or whether multiple outputs may destroy one input. Done means the required representation and consistency behavior are agreed and the affected cases are covered.