Adding support for Machine Integer version of Bytes, List, and MInt functions

[Robertorosmaninho]

This PR introduces the concrete implementation of the following new Machine Integer hooks:

1.  syntax {Width} MInt{Width} ::=MInt{Width} "^MInt" MInt{Width}
2.  syntax {Width} Bytes ::= MInt2Bytes(MInt{Width})
3.  syntax {Width} MInt{Width} ::= Bytes2MInt(Bytes)
4.  syntax {Width} MInt{Width} ::= lengthBytes(Bytes)
5.  syntax {Width} Bytes ::= padRightBytes(Bytes, length: MInt{Width}, value: MInt{Width})
6.  syntax {Width} Bytes ::= padLeftBytes(Bytes, length: MInt{Width}, value: MInt{Width})
7.  syntax {Width} Bytes ::= replaceAtBytes(dest: Bytes, index: MInt{Width}, src: Bytes)
8.  syntax {Width} Bytes ::= substrBytes(Bytes, startIndex: MInt{Width}, endIndex: MInt{Width})
9.  syntax {Width} MInt{Width} ::= Bytes "[" MInt{Width} "]"
10. syntax {Width} Bytes ::= Bytes "[" index: MInt{Width} "<-" value: MInt{Width} "]"
11. syntax {Width} MInt{Width} ::= size(List)
12. syntax {Width} List ::= List "[" index: MInt{Width} "<-" value: KItem "]"
13. syntax {Width} KItem ::= List "[" MInt{Width} "]"

Most of these hooks have an initial implementation for 64 and 256-bit Integers, being the former defined in C++ in its respective collection file while the latter is defined in the llvm_header.inc file, as C++ doesn't support 256-bit integer natively.

The only exceptions for now are 12 and 13, which are only implemented for 64-bit, as we have the immer limitation that the index should be a in64_t.

[dwightguth]

I'd suggest considering the following two factors regarding the hooks added:

1. Is there a particularly compelling reason why both arguments of hooks with more than one mint arg need to have the same size?
2. If a mint arg or return value carresponds to a size in bytes or in elements of something in memory, you should be able to use a non parametric mint 64 for it.

None of this is absolutely necessary but if we're adding hooks to the frontend we ought to think about this.

[dwightguth]

hook_list_size_long already does this. Check for other similar duplicates that may exist.

[Robertorosmaninho]

But it can return a 32-bit in 32-bit machines, right? As in CreateTerm.cpp, we set this return type fixed in i64; wouldn't it be better to be sure we're always returning the correct type?

[Robertorosmaninho]

Is there a particularly compelling reason why both arguments of hooks with more than one mint arg need to have the same size?

Not necessarily, but that's how we defined it in the frontend. We also haven't reached the need to use 2 different bit sizes as well.

If a mint arg or return value corresponds to a size in bytes or in elements of something in memory, you should be able to use a non parametric mint 64 for it.

I agree, and it makes sense, but it will enforce a roundMInt to users of this function if they're using a type different from i64, right? In our case, we're mainly using i256 in EVM, so if we enforce an i64 here, we'll have to delegate the responsibility to truncate the integer to the user instead of the function. My initial idea was to delegate this responsibility to the function to make the interface nicer. What do you think?

Also, @dwightguth, do you have any comments on how I can have:

1. A List return type in CreateTerm.cpp; and
2. How is the correct way to handle the list data type in LLVM IR, so we can have i256 versions of the List hooks there as well?

[mariaKt]

Thank you @Robertorosmaninho. I added only two minor comments.