WASM/Debugger: profiling kernels

Context

Fixes #3621 (closed).

For example, here is a flamegraph produced with the debugger: https://flamegraph.com/share/8c649475-e046-11ed-9b0d-d641223b6af4

Note that I've hardcoded a depth of maximum 100 calls in the generated flamegraphs, but we can go as far as we want.

One remaining issue are the function references that are not resolved and would require some work, but fortunately Rust doesn't seem to produce much of them.

Depends on !8522 (merged) to retrieve the symbols from the custom sections.

Manually testing the MR

Start from any kernel. Let's take the evm_kernel before stripping of its custom sections:

./octez-smart-rollup-wasm-debugger src/kernel_evm/target/wasm32-unknown-unknown/release/evm_kernel.wasm --inputs tezt/tests/evm_kernel_inputs/inputs.json
> profile
Starting the profiling until new messages are expected. Please note that it will take some time and does not reflect a real computation time.
... < WAIT >
Profiling result can be found in <filename>
... <Debug messages>

Now you can simply open the file in any flamegraph viewer, for example flamegraph.com or simply generate the SVG with the original tool (https://github.com/brendangregg/FlameGraph) and Firefox to interact with it:

./flamegraph.pl <file>.out > <file>.svg
firefox <file>.svg

Another good example is the echo_kernel, that reboots multiple times (you can use any input file, the one from the EVM does the trick):

./octez-smart-rollup-wasm-debugger src/proto_alpha/lib_protocol/test/integration/wasm_kernel/echo.wast --inputs tezt/tests/evm_kernel_inputs/inputs.json
> profile
Starting the profiling until new messages are expected. Please note that it will take some time and does not reflect a real computation time.
... < WAIT >
Profiling result can be found in <filename>
... <Debug messages>

And you can witness the successive reboots with the option flamegraph.pl --flamechart: it won't collpase the call stack but rather show the call stack in the order they appear. Note that the symbols are not available from .wast files. This shouldn't be hard to implement (they can probably be extracted during the parsing) but since we don't expect users to write kernels in textual format I believe this is out of scope.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR