Compile runtime backtracing to ASM and compile-time to ABI JSON (#7387)

## Description

This PR implements the compilation of the ABI backtracking, as described
in the [ABI Backtracking
RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md).

The PR closes two remaining implementation steps listed in the #7276:
- Compile runtime backtracing to ASM and compile-time to ABI JSON
- Support backtracing in forc test

### Changes in the ABI JSON and IR Compilation

#### `panickingCalls` section in the ABI JSON

Each panicking call is identified by a unique number and provided in the
new `panickingCalls` section in the ABI JSON.

E.g., for this panicking call in a module `some_module` of a package
`some_package`:

```sway
fn some_function() {
    let _ = this_function_might_panic(42);
}
```

the following ABI JSON entry is created:

```json
"panickingCalls": {
    "1": {
        "pos": {
            "function": "some_package::some_module::some_function",
            "pkg": "[email protected]",
            "file": "src/some_module.sw",
            "line": 4,
            "column": 8
        },
        "function": "some_other_package::module::this_function_might_panic"
    },
}
```

#### Encoding error code and backtrace in a `panic` revert code

The generation of the `panic` revert code is changed. A `panic` revert
code now encodes:
- the information that the revert is generated by a `panic` expression,
- the actual error code that can be located in the `errorCodes` section
of the ABI JSON,
- up to five panicking call IDs, encoded in the order of calling, that
can be located in the `panickingCalls` section of the ABI JSON.

The encoding of the `u64` revert code works as following:

```console
1_pppppppp_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC_CCCCCCCCCCC
```

- The leading `1` denotes a revert code generated by a `panic`
expression. Arbitrary user-defined revert codes will must have the
starting bit set to `0` or in other words be less then or equal to
`9223372036854775807₁₀ = 7FFFFFFFFFFFFFFF₁₆`.
- The `pppppppp` denotes the error code in the `errorCodes` section of
the ABI JSON, that identifies the actual `panic` location.
- Each `CCCCCCCCCCC` section denotes a panicking call code in the
`panickingCalls` section of the ABI JSON. The calls represent the
callstack, where the right-most code is the code of the immediate
function call in which the `panic` occurs. If all `C`s a zero it means
no-call. This will happen if the actual call-depth is less then five
calls.

#### Calculating backtrace

Ever non-entry function that can panic gets an additional function
argument: `__backtrace: u64`. The `__backtrace` to pass to a panicking
call is calculated at runtime by left-shift the existing `__backtrace`
provided by the caller function and append/bitwise OR the unique
panicking call ID of the exact panicking call. The ID of that exact
panicking call is a compile-time, compiler-generated constant as
explained above.

The detailed mechanism with examples is provided in the "Runtime
execution and bytecode and gas overhead" chapter of the [ABI
Backtracking
RFC](https://github.com/FuelLabs/sway-rfcs/blob/ironcev/abi-backtracing/rfcs/0016-abi-backtracing.md).

## Additional Changes

The `panickingCalls` section of the ABI JSON can differ between `debug`
and `release` builds which required adding support for different ABI
JSON oracle files in test that `validate_abi`. The requirement to
display a fully qualified function name in the panicking call and the
backtrace resulted in adding flexibility to displaying functions and
types in general. Adjusting affected tests was used as opportunity to
remove unnecessary dependencies to the `std` and reduced `std` libraries
in a large number of tests. Also, a cleanup is done in some parts of the
code, like, e.g., removing code duplications.

The PR implements these additional changes:
- Implements `TyFunctionDisplay` and `TypeInfoDisplay` for configurable
displaying of functions and types. Replacing current various custom
implementations of displaying with these two types, mostly in error
messages, will be done in separate PRs, with low priority. Also, display
might be improved in some edge cases. There are TODOs left in code for
such, and improvements will be done in separate PRs, with lower
priority.
- Displays full type names in warnings and errors, where expected. The
PR intentionally temporarily switches to full type names in all errors
and warnings by making that a default behavior in `impl
DisplayWithEngines for TypeInfo`. This is done so that we can easily
spot errors and warnings that should use specific `TyFunctionDisplay`
and `TypeInfoDisplay` (tests will break) and adapt those in the follow
up PR that will address #7389. That follow up PR will also address
usages of type names in LSP.
- Implements expressive diagnostics for `CompileError::MethodNotFound`
and utilize `TyFunctionDisplay` for displaying all matching candidates.
- Implements `Value::new_u64_constant` and removing duplicated code for
a common scenario of creating an IR Constant of type `u64`.
- Removes several unnecessary `clone()`s and `String` allocations.
- Renames fields postfixed with `typeid` to follow more general naming
convention for `TypeId` fields and parameters.
- Removes unnecessary dependencies to `std` or reduced `std` libraries
in tests.
- Adds support for different `json_abi_oracle` files for `debug` and
`release` build profiles. The `panickingCalls` part of the ABI JSON can
vary depending on the build profile. A test that verifies ABI JSON now
*must provide* expected oracles for both build profiles, unless a
profile is unsupported via `unsupported_profiles` test option. An
alternative was considered, to allow just a single oracle file if both
`debug` and `release` oracles are the same. The reasoning for having two
as mandatory even in that case was to gain more explicit test setup. We
can change this upon feedback if needed. The oracles have a suffix of
either `.debug.json` or `.release.json` and the name part is, as before,
one of the following:
  - `json_abi_oracle` for obsolete old encoding,
  - `json_abi_oracle.<experimental feature>` for experimental features,
- `json_abi_oracle_new_encoding` for new encoding without other
experimental features.
- Fixes #7386.
- Fixes #7388.

## Checklist

- [x] I have linked to any relevant issues.
- [x] 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).
- [ ] If my change requires substantial documentation changes, I have
[requested support from the DevRel
team](https://github.com/FuelLabs/devrel-requests/issues/new/choose)
- [x] 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.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.

Author: ironcev

.github/workflows/scripts/check-dep-versions/src/main.rs

@@ -9,7 +9,7 @@ const REQUIRED_XYZ_DEP: &str = "fuel-core-client";
 
 // Dependency names allowed (but not required) to use x.y.z format
 // Add names of common dev-dependencies here if you want to allow x.y.z for them
-const ALLOWED_XYZ_DEPS: &[&str] = &["etk-asm", "etk-ops", "dap"];
+const ALLOWED_XYZ_DEPS: &[&str] = &["etk-asm", "etk-ops", "dap", "fuel-abi-types"];
 
 // Regex to strictly match semantic version x.y.z (no prefixes like ^, ~)
 const XYZ_REGEX_STR: &str = r"^\d+\.\d+\.\d+([\w.-]*)$"; // Allow suffixes like -alpha, .1

.typos.toml

@@ -11,6 +11,10 @@ extend-ignore-identifiers-re = [
     "typ",
 ]
 
+extend-ignore-re = [
+    "(?Rm)^.*(#|//)\\s*typos:ignore$",
+]
+
 [files]
 extend-exclude = [
     "docs/book/theme/highlight.js",