Use different key-pair for running the sidecar

[thedevbirb]

In the first version of Bolt the sidecar will operate with an ECDSA private key, such that we can easily bind to an Ethereum address that we call BasedProposer in Bolt. This is useful for many reasons:

• It's easier to handle all on-chain bonding, staking and payments
• Exposing the validator's private identity is bad security practice

However, the downside is that validators normally operate with BLS12_381 private keys in the beacon chain. In our registry (where we perform the Bolt opt-in) we must somehow bind the validator identity with an ECDSA key.

To do this, we can:

1. sign a message of this type with the BLS key:

   { "address":"0xc2B6a65d53117005eC36cB7e624484D18467b37F",  "message": "opt-in request for BOLT" }

2. in the registry, verify the BLS signature against the BLS pubkey derived from a beacon-chain oracle. This verification should happen inside a function call for which the msg.sender is the Ethereum address that was signed in step 1.
3. if the signature is valid, check that msg.sender matches the one in step 1.
4. if true, update the basedProposers mapping in the registry to hold this new value.

---

Tasklist (to be updated)

• [ ] Create a mapping in the registry between sidecar public keys and validator public keys (or indexes)
• [ ] Enforce validator to specify an alternative public key before registering
• [ ] Modify the POST constraints endpoint on the relay to authenticate via this public key. Constraints are already signed there fore we only need to check is the corresponding public key is known and associated to a validator

[merklefruit]

Relevant to add: the registry contract must also implement a beacon chain oracle for validator pubkeys, such that the binding is completely permissionless.

[merklefruit]

Related to #63