Track ipc contract genesis artifacts

[cryptoAtwill]

Introduction

This PR builds on top of the previous PR: to track the ipc contract artifacts at genesis and actual deployment.

The high level idea is instead of scaning the contract byte code at init_chain, the genesis creation scans the artifacts and prepares the genesis such a way that makes the deployment a bit easier.

The gateway and registry contracts and all the facets are scanned to detect all the libraries used behind the scene. The bytecode and link references are collected into a hashmap with contract name as the key. This hashmap will be serialized and written to the genesis json.

The pending issue is to version the rust abi bindings, perhaps using rust crate version control instead of putting it in genesis.

[raulk]

Discussed sync with @cryptoAtwill, but leaving a record of that discussion for the community.

The current version of this change bundles the IPC contracts bytecode and inserts it into the genesis definition (JSON file), but there's room for extra simplification by moving the generation of the initial state tree out of the runtime entirely.

In this PR, ABCI::InitChain does this:

1. Receives the genesis parameters (inc. contract bytecode).
2. Executes the FVM to deploy the IPC contracts and forms the initial state.
3. Bootstraps the network with it, giving the user no opportunity to perform any checks on the initial state.

Instead, I propose ABCI::InitChain becomes dumber:

1. Receives the genesis parameters + initial state tree.
2. Loads the initial state tree blindly into the blockstore and sets the initial state root.

This decouples the genesis generation from the chain initialization, and enables safer extensibility down the line, where developers only need to modify/extend the genesis module and not the guts of the ABCI::InitChain to customize things like FVM runtimes, custom actors, and more.

So this is the new proposed genesis flow:

1. genesis params-from-parent: downloads genesis parameters from the parent and creates a genesis.params.json file.
2. genesis seal-state: takes the genesis parameters file, builds the initial state by calling the GenesisInterpreter on a MemoryBlockstore, exports the resulting state tree as a CAR stream, and serializes it into a genesis.sealed.json (a copy of the original genesis.params.json enhanced with the initial state tree). In the future, we could just stamp this file with the root CID and upload the initial state to a network like IPFS.

Using this approach, we can now solve Fluence's problem much better (cc @folex), by generating a genesis.sealed.json exporting the initial state tree at block 0 or 1 from an archive node. For this, we'll probably need a genesis export command.

In my opinion, this design is conducive to better modularity, separation of concerns, and safety, where genesis generation is a process that happens outside of Fendermint and its result is fed into CometBFT.

[cryptoAtwill]

Closing in favour of #1016.

[raulk]

Actually closing now ;-)