Fix Payment.create bug whereby payment_processor_id is not being used for the to_acco...

Fix Payment.create bug whereby payment_processor_id is not being used for the to_account_id

When Payment.create is used to add a payment made by a payment processor then the processor id should be passed in as payment_processor_id

The to_financial_account_id should be the one configured by the processor. The code was eroneously looking in 2 invalid places

- an unused parameter (which I deprecated & moved out to be handled in the api layer which is more 'throw away'
- the contribution - which doesn't have a payment_processor_id field & which should not be the source.

I originally thought this was a regression and did a patch against the rc
https://github.com/civicrm/civicrm-core/pull/15574

I think there is still a case to be made for putting this against the rc as it might be a regression - I just felt I
needed to slow down & sort out a test first.

Note that I have left a couple more things out of scope
1) I believe that if payment_processor_id is passed in then should use the payment_instrument_id from the processor
and not permit it to be overridden by the payment_instrument_id parameter (as is currently the case)
2) I believe that we should deprecate calling Payment.create without one of payment_instrument_id or payment_processor_id
(we might need some sugar to carry these over if chaining from Order.create
3) I believe the payment_instrument_id on the Order should be updated when the first payment comes in to
reflect the actual payment instrument, once known (of course it will still be inaccurate when there
are multiple payments of different types but at least for single payments this gets us past the issue
of it being outright wrong.