__log outputting encoded values

[xunilrj]

Description

This PR changes the output of __log to encoded values (see #4769). A quick example of what that means is

struct S {
    a: u64,
    b: u32,
    c: u16,
    d: u8,
    e: Vec<u64>,
    f: str,
    g: u256
}

let mut e = Vec::new();
e.push(1);
e.push(2);
e.push(3);

__log(S{
    a: 1,
    b: 2,
    c: 3,
    d: 4,
    e,
    f: "sway",
    g: u256::max()
});

will output

 [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 2, 0, 3, 4, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 0, 4,    115,   119,    97,   121, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255]
  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^  ^^^^  ^  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^^^^^     ^^^    ^^^     ^^    ^^^  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                     s.a         s.b   s.c s.d              s.e.len()                  s.e[0]                  s.e[1]                  s.e[2]               s.f.len()  s.f[0] s.f[1] s.f[2] s.f[3]  s.g

This works in two steps:

1 - __log(s) is desugared into __log(encode(s));
2 - call encode. Its impl can be found at https://github.com/FuelLabs/sway/pull/5306/files#diff-ee5cebc963e841e8af05f3986de17dd266ee6e9b49dbe089a5eb64764f3b802eR307

It simply creates an append-only buffer and call abi_encode from a special trait named AbiEncode.

To be encodable, a type must implement AbiEncode. In the example above, S is auto-implemented by the compiler because all its fields are AbiEncode. But we can also have custom impl like Vec here: https://github.com/FuelLabs/sway/pull/5306/files#diff-b5d9688741fea479477f26ca44cd1d1ecbd2f003f3875292abb23df7fad85c58

All this is behind a compiler flag:

> forc build -h
Compile the current or target project

USAGE:
    forc build [OPTIONS]

OPTIONS:
...
        --experimental-new-encoding
            Experimental flags for the "new encoding" feature

The same flag is available for the e2e tests:

> cargo r -p test --release -- should_pass/language/logging --verbose --experimental-new-encoding

Limitations

1 - Now that __log demands a fn called encode, when something is compiled with implicit-std: false, the intrinsic function __log does not work out-of-box anymore. A function called encode must "visible" and the worst part is that it needs to be functional to log anything.

2 - Arrays, string arrays and tuples will have limited implementations. Currently up to five items.

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]

Some tests are breaking because of #5383. The problem is that when we generate the auto impl, it ends up resolving to the wrong types.

[xunilrj]

The task to test std-lib does not work, because it depends on the SDK parsing the log correctly. Something we still need to do.

[jjcnn]

I'm not sufficiently familiar with most of the code being touched here, so I don't feel comfortable giving a review a such.

I did want to raise the issue of whether it's possible to go from the log output back to the data? The type of the data doesn't seem to be part of the encoding, so to map the log back to the data it came from you would need to supply the types separately.

[xunilrj]

whether it's possible to go from the log output back to the data?

Only looking at the bytes... no. But this was a explicit decision (that we can discuss if is a good one or not).
For that, and specifically for logging, you will have to look ate the ABI JSON.

"loggedTypes": [
    {
      "logId": 0,
      "loggedType": {
        "name": "",
        "type": 5,
        "typeArguments": []
      }
    },
    ...

The test that test this is the one broken because we need to update the Rust SDK. What we do in that test is running a macro on top on this JSON that "recreate" all the types and give you easy access to all typed logged data.

Unfortunately both repos are dependent on one another. :(

[IGI-111]

A few nitpicks but LGTM

[JoshuaBatty]

Looks good, excited to see this land.