Handle the valset genesis case correctly

[rach-id]

Problem statement

As discussed in #351 (comment),
The case is for the following scenario:

• You start a Celestia chain. It creates on block 0 valset.Nonce=1
• You deploy a QGB contract using that chain
• The QGB contract will now have valset.Nonce=1 as valset0
• Then, when you want to relay valset.Nonce=1 to the QGB
• To do so, you need to get the signatures of valset1 using validators from valset1 (which is valset0 in the QGB contract)

Live example on Rinkeby: https://rinkeby.etherscan.io/address/0xEAcC249c0831f8DE0B6afe27e6179Ca29Dec9b74#events
Check the first two events:

• First event is the deployment event. It has nonce 0
• Second event is relaying valset.Nonce=1
  You can see that the threshold and the validator set hash are similar.

Possible solutions

Either update the QGB contract and remove this case. Or, document this case somewhere.

Originally posted by @sweexordious in #351 (comment)

[rach-id]

This is updated to have the first valset having nonce 1, and not relaying it again.
The problem was that we were deploying the QGB contract with valset nonce == 1. Then, we start relaying, we're re-submiting the first valset again.