Add proper handling of undef values

[surovic]

https://llvm.org/docs/LangRef.html#undefined-values

Relates to #158

[artemdinaburg]

Left a comment on the PR, but putting it here as well:

So I had to read the undefined value description a bit more.

An undef (if not frozen, which we have not run into yet) can take any value. This is not undefined behavior, but an undefined value.

My opinion is that:

1. This is probably due to some anvill issue, and anvill should definitely have a pass to see if undef leaks out to final bitcode.
2. We may have undef as a legitimate source into rellic, if, say, the ISA specs for some instruction specify a register is in an undefined state, and then the register is used.
3. The current behavior (assume that an undef pointer is NULL) is perfectly valid, since it can indeed be NULL.
4. For this specific PR, we should return a constant integer of 0 of the right bit width (not cast to a pointer, as this is an int value). I will see if I can make the change.
5. From a correctness and "what does the user expect?" standpoint, I think we should pick a value (say, zero) and emit function call like:

int32_t rellic_undefined_value_int32() {
#pragma error "The input bitcode uses an undefined value. This may not be an error, but it probably is. Uncomment this pragma to achieve recompilable code.
return 0; // any value works here
}

...
int var0 = rellic_undefined_value_int32();
...

The user of the decompiled code can then figure out what they want to do about the undef, and static analysis tools should be trivially able to see that rellic_undefined_value_*() returns 0 (or 42 or whatever we pick).