bark: Introduce Round state machine to make round participation more robust

The original goal of this PR is to store participated rounds and their latest known state on bark client to improve reliability. This unlock several check so that client knows what to do with an ongoing round:

• round that are pending chain confirmation will be monitored and only be considered as done when round tx is seen onchain
• round whose forfeit txs were signed can have input monitored and be considered cancelled if it is deeply confirmed onchain
• client could reconnect and continue an ongoing round if it didn't miss a step (out of scope)
• client can keep track of rounds where forfeit were signed but never went onchain (if it is seen onchain, then the round would be confirmed, old vtxos spent and new vtxos created)

It has evolved into also decoupled the round logic by moving it to the state transition

To accomplish that, we:

• moved the round attempt logic to its own function, to guarantee it cannot early return without leaving the ongoing round
• added round entity in the database
• created a state machine on top of that round
• divided the round attempt logic in each state transition
• added logic to sync ongoing rounds
• updated tests

Follow ups needed on this PR:

• monitor all forfeitsigned states of rounds that are still neither cancelled nor confirmed
• catch up round for rounds in attempt started/payment submitted/vtxo signed state