Convert SignalService into a library consumed by a CommitmentSyncer

[ernestognw]

Turned the SignalService into a library so that applications can use it to signal values. The meaning of such values depend completely on the application.

Also, a CommitmentSyncer is added, who's in charge of syncing the most recent commitment per chain id by using storage proofs. The only condition is that a trusted state root is required.

[nikeshnazareth]

I did the renaming and a little bit of cleanup.

I think there are still some build problems associated with the Signal Service that I am ignoring.

I'm not quite clear on what verifyCommitment (previously verifyState) achieves. As I understand it, the relevant signal will be created in syncCommitment (previously syncState) on the relevant chain, and it will be included in the Signal Service on that chain.

We're then checking that the signal exists in that chain's commitment, which I guess makes sense because it will be a record in that chain. But where do we get that chain's commitment from? Is that solved at a higher level by whoever calls this contract?

[nikeshnazareth]

I modified verifyCommitment so that it includes both a commitment and a state root. The thought is:

• a commitment is a generic item that represents everything the rollup needs to care about at some point in time.
• at the moment we treat it like the L2 state root but it could be the L2 block hash, or a combination of L2 block hash / and embedded rollup hash / L1 state / whatever
• whoever is calling verifyCommitment is checking that the commitment signal is somewhere inside the state represented by the commitment. They should be responsible for retrieving the state corresponding to the commitment (which in our cases is identical to the commitment)