u128/i128 support in FFI

[mversic]

The implementation after #2625 is outright wrong. u128/i128 is not FFI safe and cannot be sent across without serialization. I propose it to be serialized as FfiTuple2(u64, u64) or [u64; 2]

[mversic]

here is the tracking issue.

As far as I see u128 can be serialized in the following ways:
1.

#[repr(C)]
struct U128(u64, u64);

#[repr(C)]    // Note that I haven't used `repr(transparent)`
struct U128([u64; 2])

Idk if there is any difference between the two. The only potential difference that I can think of is that of the calling convention

In 2. I have used repr(C) due to a concern raised here. Whether or not repr(transparent) can be used in this case depends on whether the calling conventions for array and struct match but this is not something that should be depended upon unless confirmed

[appetrosyan]

There are many C compilers and even more compilers that assume C-ABI behaviour.

I would very much prefer the first option, unless there was a good reason to use the second syntax.

In a vacuum (i.e. without ABI considerations) the first syntax is more explicit about the fact that you should really destructure both and use both parts of the value. You also don't add the baggage of iter() and many other things which don't map onto u128's real usage. The only case where the latter syntax would have been preferred is if the type u256 existed and we also needed to wrap it.

[AlexStroke]

No code currently relies on this, but if it did it would be a bug.

[appetrosyan]

Then it's really good that this is a WIP, rather than in production. If we're labelling hypotheticals as bugs, we should add the QA-confirmed tag to all issues.