Store Chain Id in runtime storage

[JoshOrndorff]

This PR solves the problem of all moonbeam chains having the same chain id. The implementation chosen is to introduce a simple pallet that stores a u64 chain id in runtime storage. This solution is simple, and compatible with existing evm and ethereum pallets.

This PR does not use the SystemChainId type available in pallet_evm because it relies on a host function that is not well documented or understood. While we could introduce a custom host function to make that approach work, it adds complexity, and pushes concern about setting the right chain id to node operators.

This approach has lots of room for growth including:

• Changing the chain Id via governance
• Being combined with other configuration information such as those stored in parachain info

This PR also includes one mostly unrelated change. It adds empty genesis config entries to all the json-encoded spec files in the repo. This will ensure we can get ethereum block 0 via rpc when using these json specs.

[crystalin]

It looks good but we should discuss the chainId we will provide. I took 43 cause substrate was 42 (which is also Kovan) but we might want to go wither other values.

[tgmichel]

May I suggest a rename for the pallet?

I propose calling it just a more generic pallet-evm-chain-id, simply because it is self-describing and can be plugged into non-moonbeam projects that use EVM or Frontier without any rebranding.

[JoshOrndorff]

After discussion on Slack we decided to go with these chain Ids

Local parachain testnet 1280
Local standalone testnet 1281
Reserved for other testnets 1282 - 1283
Moonbeam 1284 (mean milliseconds for a moonbeam to reach earth)
Moonriver 1285
Moonrock 1286
Public parachain testnet (currently alphanet) 1287
Reserved for other public networks 1288 - 1289

I'll update the code and rename the pallet as Telmo suggested, then i think we're good to go.

[crystalin]

Needs to update the chainId in the hardcoded specs