At closer inspection, almost all logic around which payment actions to
display involves only the state of the payment. So I moved the logic
there.
We now have one list of all possible actions supported by the UX. Then
payment methods can declare a list of supported actions. If that's
conditional, they can implement the conditions themselves. The payment
model itself then still filters the actions based on its state.
This implicit delegation makes it impossible to know which code is used
and which code is dead. The refund method is very rarely used though. So
we'll need to wait for a while.
