Use a relative timelock

[JssDWt]

The absolute timelock used poses challenges. Namely the user has to get his locking transaction confirmed in a reasonable period, otherwise the swap will timeout before it has even started. In this PR, the timelock is changed to a relative timelock.

• Changed the code to use a relative timelock
• Changed the payout function to look at all outputs, not just utxos. The first confirmed output for a swap address defines the entire swap's timeout height.
• Added integration tests for unilateral refund to ensure outputs cannot be unilaterally refunded before the relative timelock expires. (I could NOT figure out which parity to use in the taproot control block. Hance that code in the test now contains a hack of trying both parities)

[JssDWt]

Fixed the RBF test. There was an issue calculating the blocks left.

Also caught an issue where the claims were not inserted, thankfully caught that in the process.

[roeierez]

Looks good! One small comment.