feat(operator): load genesis state

[MaxMustermann2]

This PR subsumes #25 within itself, and therefore should be merged after that one. For ease of review, this PR may be reviewed after the merge of #25 happens and this PR is rebased.

The x/operator module should load the genesis state from disk for the network to successfully bootstrap with the rPOS process. This pull request makes that happen.

The genesis state is structured as follows:

{
    "operators": [
          {...}, {...}
    ],
    "operator_records": [
        {
            "operator_address": "exo1...",
            "chains": [
                {
                    "chain_id": "exocoretestnet_233-1",
                    "consensus_key": "0xFFFFAAA...."
                }, {...}
             ]
        }, {...}
    ]
}

At genesis, the module should:

• Register all of the operators
• Opt them into the chains (for which the consensus key is provided)
• Store the provided consensus keys against the operator address + chainID combination

The stateful validations performed are the same as the validations on a live chain, since all the calls are routed to those very functions.

The stateless validations are listed below.

• The operator addresses in operators list are of the correct bech32 format.
• The client chain earnings addresses, if provided, have unique LayerZero chain ids (for that operator), and the value of those addresses is an Ethereum hex-address (TODO: make this format dependent on the lzID).
• The operator addresses in operator_records list are correctly bech32 encoded.
• The operator in operator_records exists in operators.
• The provided consensus keys are unique for the chainID.
• The consensus keys can be parsed from hex (Solidity's bytes32).

[TimmyExogenous]

LGTM