Add ECAL opcode

[lostman]

Description

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[xunilrj]

Do we have a specific use case in mind?

Because although this "works", makes sense to realize that this will be something like "unsafe" for Rust, because the external function being called can kill any/all optimizer assumptions.

From Fuel doc:

The operation can modify the VM state freely, including writing to registers and memory.

I am not sure how we want to deal with this opcode, because this can potentially generate buggy code that will almost impossible to debug.

[IGI-111]

the external function being called can kill any/all optimizer assumptions

This is by design. I believe asm blocks already are treated as black boxes by the optimizer, aren't they?

But yes, this is an escape hatch, we shouldn't optimize around it but it's meant to allow for behavior that isn't necessarily safe (including debugging).

[IGI-111]

In any case, this needs testing, at the very least to validate that the opcode gets compiled correctly.