Consider making panic op take tuples rather than type rows

[cqc-alec]

It might be slightly better in terms of future-proofing to have this op take tuples of inputs and outputs, instead of rows. My reasoning is that in the future, when we have row kinded type params, we should be able to define this op without needing compute_signature.

I.e. inputs : Row. outputs : Row. panic : Error, Tuple(inputs) -> Tuple(outputs)

If we define it in terms of tuples now, there's less friction if we rewrite it this way

Originally posted by @croyzor in #1024 (review)

[acl-cqc]

When we have row-kinded type params, we'll be able to use a typescheme to generate a panic op-node with a variable number of inputs/outputs. I presume that's what we've got ATM, but we won't need a binary compute_signature anymore.

In the meantime we could drop the binary compute_signature of #1024 if we took/returned tuples, but that moves away from the ideal interface (taking/returning multiple values) in order to simplify our implementation sooner. I wouldn't worry about that (?).

Suspect either I'm confused about what panic does or your confused about what row-variables will enable, so if not clear, let's talk IRL...

[doug-q]

I'm not up with typeschemes but I think the non-tuple interface is better, even if compute_signature is required.

[doug-q]

I'm closing as we agreed we didn't want to do this. @croyzor Please do reopen if you disagree.