don't store UntypedInt with 4-bit APInt values

Integer 8 is represent as b1000 in a 4-bit APInt manner.
Later, when we translate this APInt value into a const using
APInt.sextOrTrunc, we get b11111000 back, which is not what
we want. The bad intepretation only occurs when
we infer the type of an integer, i.e., an integer without :iN.
Note that b11111000 is unsigned char 248, which is why we see
instruction "%8:i1 = eq 248:i8, %0" in John's example.

The fix is to use multiple of 5. It should always be safe.
Also, we won't increase too much memory usage because
it's only for parsing replacements, which are small.
Merge pull request #125 from chenyang78/parser

don't store UntypedInt with 4-bit APInt values
add Raimondas's souper2llvm tool

a couple of improvements to cache dump tool:
- call souper2llvm if asked
- keep track of optimization srclocs as we process things