Improve error message with mismatched valtype/dtype

[jacobhinkle]

We already check types when binding arguments, but now we explicitly state which arguments mismatch, and in which positions.

Fixes #2670 by improving the error message. Before this change the error message was

Expected T0_g[ iS0{i1} ] to be bound to an at::Tensor, but got l

After this PR, the error is

Expected input 0, T0_g[ iS0{i0} ], to be an at::Tensor but got scalar 2

[jacobhinkle]

!build

[tfogal]

That error message is a great improvement! Thank you.

[jacobhinkle]

This is not an ideal fix since it replicates (poorly) the validation that already exists in ExpressionEvaluator::bind. I did it this way to be able to provide the argument number, which we lose once we get to the bind call. I'll try again to just improve the error message locally within bind and omit the argument number for now. In the future, it might be nice to be able to declare error contexts with guards so that additional info is printed. For example in bindInputs we could have:

for (const auto i : c10::irange(inputs.size())) {
  ErrorContext e("Error binding input " + std::to_string(i));
  expr_eval.bind(inputs[i], *args[i], true);
}

Then if NVF_CHECK or NVF_ERROR fails inside the lifetime of e, we would get an error message like Error binding input 2: <actual error>. That's a more general problem that we should handle separately (I'll post an issue for it). For now I will just try and clean up the bind error messages and revert the current changes.

[jacobhinkle]

I fixed this up by determining the input position inside the bind_ call when a check fails. I also added some cases to the test to check that our error messages work properly for other kinds of malformed inputs.

[tfogal]

Re-+1'ing the new changes.

But I also want to plug #1758: I'd really encourage an up-front pass to validate as soon as we can. As we found with latency work (#2136), ExprEvaluator is on the critical path, and so I worry about adding more checks in there.

Admittedly--these checks have to be on the critical path (since we can only validate when we see what inputs we actually receive). But it would probably behoove us to do an up-front check for UX purposes and avoid checks inside each Expr evaluation.