Fix capture action retry payment after abandoning checkout

[TheMilek]

fixes #329

How it is fixed

StatusAction maps open to markNew(). open means nothing happened and the session is still payable, which is what new means in Sylius. processing is now reached from pending, where the customer has committed on the PSP side. No core change needed, both gates are satisfied by the payment telling the truth.

ConvertMolliePaymentAction carries the tracked ids into its result. Not a separate decision, the price of the one above: Payum\Core\Action\CapturePaymentAction re-runs Convert on every capture while the status is new and replaces Payment::details with the result, so without carrying payment_mollie_id over, CaptureAction cannot recognise the session it created and builds a competing one each round trip.

CaptureAction delegates to ExistingMollieSessionResolver, which answers with one of three decisions, in order:

• leave it to the status flow, when the resource is not open, or when the request arrived on the same Payum token that is the resource's redirectUrl. Mollie redirects back to the token that created the session after every attempt, abandoned ones included, so that equality identifies a return rather than a new intent. This is the cut that closes the loop.
• resume, when the method on the resource matches the requested one. The method reaches Payment::details only through a form submission, so equality means nothing new was chosen. We PATCH redirectUrl to the current token and redirect to the existing checkoutUrl. The PATCH is needed because CaptureController::doAction() invalidates the token once execute() returns normally, so without it the customer would come back to a dead token after paying.
• replace, when a different method was chosen. The old session is locked to the old method, so it is cancelled where Mollie allows it and exactly one new session is created.

One Mollie payment per order, plus one per deliberate method change.

The orphan log moves to error level so it survives realistic gateway settings, and says that money was collected and needs review.

Once an order is placed, only surcharge neutral methods are offered. PaymentSurchargeProcessor bails on !$order->canBeProcessed(), which is state === STATE_CART, so after checkout the total can no longer follow the method: switching from a 5.00 fee to a 4.00 one left the order charging 5.00. MolliePaymentsMethodResolver now offers only methods whose surcharge equals the one already on the order. The selected method's surcharge is by construction the one that produced the adjustment, so the list never comes back empty, and nothing changes during checkout.

To compare surcharges without reimplementing them, the fee calculators gained PaymentSurchargeAmountCalculatorInterface, reporting an amount instead of applying it, and calculate() delegates to it so the two cannot drift apart.

[TheMilek]

allows to choose different payment method