capstone2llvmir: nondeterministic integer number base in unit tests

One instance (so far) of Windows continuous Integration (Appveyor) failed on the following error:
```
retdec-tests-capstone2llvmir.exe
C:\projects\retdec\tests\capstone2llvmir/capstone2llvmir_tests.h(609): error: Expected equality of these values:
val.ui
Which is: 4804
getRegisterValueUnsigned(reg)
Which is: 4840
register = rcx
function: ""
bb: "bb"
0 : store volatile i64 0, i64* @0
4660 : %0 = load i64, i64* @rax
10 : %1 = load i64, i64* @rdx
80 : %2 = mul i64 %1, 8
4760 : %3 = add i64 %0, 100
4840 : %4 = add i64 %3, %2
4840 : store i64 %4, i64* @rcx
unknown : ret void
[ FAILED ] InstantiateX86WithAllModes/Capstone2LlvmIrTranslatorX86Tests.X86_INS_LEA_64/CS_MODE_64, where GetParam() = 8 (2 ms)
```

This test emulates this instruction: `lea rcx, [rax + rdx * 8 + 64]`.

It expects: `X86_REG_RCX == 0x12c4 == 4804`.

The expected value trace is:
```
0 : store volatile i64 0, i64* @0
4660 : %0 = load i64, i64* @rax
10 : %1 = load i64, i64* @rdx
80 : %2 = mul i64 %1, 8
4724 : %3 = add i64 %0, 64
4804 : %4 = add i64 %3, %2
4804 : store i64 %4, i64* @rcx
unknown : ret void
```

It looks like in the failed instance, Keystone (probably), or some other tool in our chain, decided to use a different base (hexadecimal) for value 64 in the emulated instruction. I have no idea why. Maybe this will never happen again and it is just some strange bug in the matrix.

Start by rerunning the capstone2llvmir unit test covering X86_INS_LEA_64 and inspect tests/capstone2llvmir/capstone2llvmir_tests.h around line 609. Compare the generated trace for `lea rcx, [rax + rdx * 8 + 64]` with the expected decimal value 4804 across the affected Windows configuration. Done means the test is deterministic and passes with the intended value.

Written by the indexing model from the issue text.