Fix expiry status flow

[marsella]

Closes #298

Three main changes in this PR:

• Fixes status flow. @indomitableSwan , can you confirm that there is no scenario where a unilateral customer close would be permissible, but a unilateral merchant close would not be (and vice versa)?
• Updates with_closeable_channel function to account for the change. This was hardcoded to only transition into PendingClose, but it actually should also permit PendingExpiry.
• Updates logging in the test infra. This is not perfect, but it was previously only logging things from stderr at termination, which missed a lot of important inline / non-fatal errors. It now logs all of those, and also everything else (including non-error info) that zeekoe logs using stderr. This over-information problem would be solved by #91 (or another more nuanced logging approach).

[indomitableSwan]

Closes #298

Three main changes in this PR:

• Fixes status flow. @indomitableSwan , can you confirm that there is no scenario where a unilateral customer close would be permissible, but a unilateral merchant close would not be (and vice versa)?

Can you clarify terminology here? Not entirely sure what you are asking.

That said, a desired property of the scheme is that either party can force an open channel to close at will.

At the chain level, this means that either party can (start to) close an open escrow account at any time. The chain is happy to receive either an expiry message from the merchant, a close message from the customer, or a mutual close message (for Tezos, I think we designated this as from the customer?), so long as the escrow account has status OPEN.