Develop getter & setter structure for Payment classes

I don't think anyone designing Payment Processing subsystem would include the spec that you pass an undefined set of parameters to the 'doPayment' method, but that is how ours grew up.

This has caused us issues with inconsistencies around how payment processors determine variables. It also makes it really hard to clean up the code that interacts with payment processors as the code spends a lot of time buying arrays which go off into the void.

I'm pretty sure that if we were designing from scratch we would make it look much more like

$paymentObject = $this->getPaymentObject();
$paymentObject
  ->setContributionID(5)
  ->setContactID->(6)
  ->setAmount(50)
  ->setInvoiceID('xyz')
  ->setRecurringFrequency(1)
  ->setRecurringUnit('week')
....
->doPayment();

$feeAmount = $paymentObject->getFeeAmount();

We might provide some helpers etc but that seems much more inline with modern coding conventions and with our desire for standardisation.

I believe we should start adding getters & setters & encouraging payment processors to use them. The getters would do any normalisation of parameters (I'm looking at you currency vs currencyID).

It would be quite some time before this usage has 'flowed through the system' & we switch to relying on it when making payments but I think that adding this structure sets us up well for the future.

See PR for proposed change - which will not ACTUALLY change anything other than make these methods available in the first instance https://github.com/civicrm/civicrm-core/pull/15509

@artfulrobot @KarinG @adixon @mattwire @andrewhunt

(Payment\PropertyBag)