Uint256Add hinter

[cicr99]

Fixes #187
Fixes #219

[cicr99]

I added a few modifications to the implementation of Uint256Add hint in the last commit, so we could use the same one for Uint256AddLow hint, as most of the logic is the same for both

[quasilyte]

Doesn't the current 1 field per operander approach work in this case?

[cicr99]

Doesn't the current 1 field per operander approach work in this case?

Unfortunately no. The hint uses a and b as the parameters for the addition, and they are both of type Uint256, so it's actually two felts each one.

[quasilyte]

Take a look at https://github.com/NethermindEth/cairo-vm-go/tree/quasilyte_uint256_hint_review

I treat operanders list as a memory initializer: the "name" doesn't need to store an entire object, if you want to pass an object as a parameter, passing its beginning is enough since we can then resolve its address to read consecutive felts from the memory.

[cicr99]

Mmmm, that's true. It's certainly more comfortable to write the tests that way, and also I think it's more readable than just passing an array full of values. Yep, I like it. Will change

[quasilyte]

I've left a couple of comments, but nothing that keeps this PR from being merged.