Fix payment instrument bug by using correct payment instrument

[eileenmcnaughton]

Overview

Per #17589 it is necessary that we do NOT pass the wrong payment_instrument_id
to the payment processor. BUT we have to provide accurate defaults for manual payments.
This fixes the function that gets the default to get it from the relevant processor.

This is a narrower fix than Per #17589

• back office membership form
• back office participant form
• back office contribution form

and in all cases the Manual processor still loaded correctly.

I don't feel I can say this is the last fix in this
area but it stands alone as a sensible fix to do and also one that should address the immediate issue and can reasonably go in the rc / potentially backported.

Note there is some weirdness in a second function in EventFees - that function should GO IMHO - but I have not yet reached it in
UI testing to confirm if other changes need to be made.

Before

If the payment_processor_id is not set by the user the default is the main site default

After

If the payment_processor_id is not set by the user the default is the default appropriate to the processor

Technical Details

Comments

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).