Refund timelock should be in seconds not in blocks

[bonomat]

Currently the refund timeout is depicted in blocks

https://github.com/comit-network/hermes/blob/d8b5b6498bcd4fc5fdb5df6d9b183e4edc09b268/cfd_protocol/src/lib.rs#L665

This is risky as the contract term expires at a fixed point of time, i.e. when the oracle publishes the attestation. Refund should be possible shortly afterwards.
(Note: We cannot use an absolute timelock here because it would allow a malicious user to publish an old state and immediately publish the refund transaction.)

On average Bitcoin has a block every 10 minutes. There are times when blocks are showing up faster or slower. I can happen that a relative timelock in blocks could be faster than a relative timelock in seconds.
Hence, it could happen that the refund timelock expires faster than expected allowing an user to refund before the oracle would publish its signature.

Our API would support witching from blocks to time easily but care should be taken when doing so:
see https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.

If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.

The sequence number encoding is interpreted as follows:

Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.

The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).