Make the operand ordering of conditional branches less confusing.

In LLVM, a conditional branch (in textual representation) looks like:
```
br %cond, bb-if-true, bb-if-false
```

But under the hood, the operands are stored in a different order:
cond, bb-if-false, bb-if-true

This led us to invert all of our guards in our traces!

Rather than inherit this oddity in our IRs, this change re-jiggles the
operand ordering during lowering to make it how you might expect.

Author: vext01

llvm/lib/YkIR/YkIRWriter.cpp

@@ -449,12 +449,28 @@ class YkIRWriter {
       OutStreamer.emitInt32(0);
 
       VLMap[I] = {BBIdx, InstIdx};
-      InstIdx++;
     } else {
+      // type_index:
+      OutStreamer.emitSizeT(typeIndex(I->getType()));
+      // opcode:
+      serialiseOpcode(OpCode::CondBr);
       // We DO need operands for conditional branches, so that we can build
       // guards.
-      serialiseInstGeneric(I, VLMap, BBIdx, InstIdx, OpCode::CondBr);
+      //
+      // Note that in LLVM IR, the operands are ordered (despite the order they
+      // appear in the language reference): cond, if-false, if-true. We
+      // re-order those during lowering to avoid confusion.
+      //
+      // num_operands:
+      OutStreamer.emitInt32(3);
+      // OPERAND 0: condition.
+      serialiseOperand(I, VLMap, I->getOperand(0));
+      // OPERAND 1: block to go to if true.
+      serialiseOperand(I, VLMap, I->getOperand(2));
+      // OPERAND 2: block to go to if false.
+      serialiseOperand(I, VLMap, I->getOperand(1));
     }
+    InstIdx++;
   }
 
   void serialiseGetElementPtr(GetElementPtrInst *I, ValueLoweringMap &VLMap,