fix: do binary stack scheduling optimizations only for the binary ops (implementing BinaryOp trait)

[greenhat]

Close #600

This PR:

• checks that the op is binary if it implements BinaryOp at HirLowering::schedule_operands();
• simplifies the test_arg_order test and moves it to the misc module;

[bitwalker]

Copying my reply from Slack here for visibility:

It's not actually correct though. The conclusion it drew about the original code that swaps the operand order for BinaryOp impls completely ignores the comment that explains the reason why that swap is performed only for BinaryOp impls and not any operation with only two operands.

The later "binary" operand handling has nothing to do with binary operations, but operations where there happen to be only two operands, so the scheduling of those operands can be done very efficiently (i.e. without going through the operand scheduler).

So this change may have caused the test to go green, but for the wrong reason - i.e. it didn't fix the actual bug.

It looks to me like the actual bug here is in the manual implementation of operand scheduling for two operands. The fact that hir.exec doesn't implement BinaryOp is irrelevant - that's not why we're manually handling the binary operand case like that; we're doing so to avoid going through the more expensive operand stack solver which is not optimized for such trivial cases.