[Bug] Incorrect scf.for code is generated

Nobody has claimed this yet.

The following C code generates wrong mlir code
```C
int foo(int num) {
int sum = 0;
int i = 0;
for (; i < num; i += 5) {
sum += i;
}
return sum + i;
}
```
```mlir
func.func @_Z3fooi(%arg0: i32) -> i32 attributes {llvm.linkage = #llvm.linkage} {
%c0 = arith.constant 0 : index
%c5 = arith.constant 5 : index
%c0_i32 = arith.constant 0 : i32
%0 = arith.index_cast %arg0 : i32 to index
%1 = scf.for %arg1 = %c0 to %0 step %c5 iter_args(%arg2 = %c0_i32) -> (i32) {
%3 = arith.index_cast %arg1 : index to i32
%4 = arith.addi %arg2, %3 : i32
scf.yield %4 : i32
}
%2 = arith.addi %1, %arg0 : i32
return %2 : i32
}
```
This instruction `%2 = arith.addi %1, %arg0 : i32` is wrong because `num` is not necessarily a multiple of 5

Start with the C reproducer and compare its loop semantics with the generated MLIR scf.for shown in the issue. Trace the C-to-MLIR lowering for the loop and verify that the value used for the final return reflects the actual post-loop value of i, including when num is not a multiple of 5.

Written by the indexing model from the issue text.