Audit numerical corner cases

[burmako]

(Please note that this ticket is different from #1156 which talks about numerical accuracy).

When writing the initial version of the spec, we've abstracted ourselves away from numerical corner cases, stating that "Error conditions are [...] possible, e.g. through integer overflows, out-of-bounds accesses, etc. Unless explicitly called out, all these errors result in implementation-defined behavior. [However] as an exception to this rule, floating-point exceptions in StableHLO programs have well-defined behavior [...] defined by the IEEE-754 standard".

This was convenient for the initial version, but this way we not only deferred figuring out error conditions (desired effect) but also missed some interesting corner cases like #1150 (undesired effect). Before we release StableHLO v1.0, it would be good to audit the opset and address both items.