Allow payments to be converted to another currency

This may tie into #2037081: Distinguish between amounts charged and paid.

The original philosophy behind Payment is that payment entities reflect real-world payments/transactions and they are not invoices. There amounts that are charged, are set on the line items. The amount that is paid, is the payment amount itself. The latter can change, depending on the real-world payment the entity reflects. This is also why we cannot fix #2334237: Consider removing line item's currencies, because line items contain the amounts that are charged, and they may be dynamically based on referenced data, such as orders.

Instead, allow payment methods to change a payment's amount and currency, and add line items after payment execution to balance out any differences between the charged amounts and the paid amount. This way the line items still contain the original charged amounts, but the payment amount and currency reflect reality.

Add a PaymentLineItemCollectionInterface that gets the methods for the charged amount, as that's what line items represents. Keep the methods for the paid amount on PaymentInterface.

Payment types, however, must be able to work with the paid amounts. If they charge in EUR, but are paid in USD, they may not be able to figure out if the charged amount was paid completely. How will we deal with that?

So there are three types of amounts we have to deal with:

1. The amount that is charged. This is contained in the line items and may have to be converted to a single currency for further processing, as line items can specify amounts in different currencies.
2. The amount that is paid in a currency of the payer's preference: the charged amount may be in EUR, but if the payer would rather like to pay in UAH and the payment method allows that, this amount is different from the oher amounts.
3. The amount that is paid in a currency of the payment type's preference. This is needed to find out if the payer paid enough to cover the originally charged amount.

In essence only 1 and 3 are necessary for the system to function. 2 is really more of a reference for the payer to match a payment entity to a transaction on their back account. We can start by implementing 1 and 3, and add 2 later if there is a need for it.

Re-roll.