feature: make Kakarot chainID less or equal than 4 bytes for compatibility with Ledger Live "clear signing" flow

[Eikix]

To comply with Ledger Live Clear Signing, max chainID is not MAX_SAFE_CHAIN_ID as we today have but rather 4 bytes.

Impact of having >4bytes chainID (told by Ledger Team):

you'd be able to sign your transactions just fine, but providing metadata to the device for like decoding the calldata and displaying informations using things like tickers, decimals etc, all of that is signed by ledger, and the whole signature scheme assumed that a chainId is max 4 bytes

Documentation of the Ethereum app here: https://github.com/LedgerHQ/app-ethereum/blob/develop/doc/ethapp.adoc
ERC20 example:

Context: ChainIDs ~20 networks today are higher than 4B, out of like the ~2000 you can find on chainlist

[ClementWalter]

So there is a conflict between hive tests and this constraint.

There is also another topic for chain id : if we want to have several kakarot on the same underlying sn chain (like staging, pre prod and prod), then they can't have just all the same chain id.

Let's use (back) a storage var that we set in constructor, and no setter entrypoint