Use correct...er flow to create partial payments on events

Use correct...er flow to create partial payments on events

This fixes the methodology for recording partial payments on the backoffice contribution form to create a pending contribution (order)
and then add a payment. The previous method was our first cut at supporting partial payments (before the Order+Payment flow) and
relies on some handling in the BAO which is crufty & has proven unreliable. This allows us to deprecate that handling & remove the
now unused addPayments function.

Prior to this PR I wrote a test for current behaviour & I had to alter that test for this as follows

1) prior to this change net_amount was clearly miscalculated & hence this fixes & I updated the test
2) prior to this change a financial transaction was created for the contribution. Now only the payment financial transaction is made.
3) prior to this change the financial item was set to partially paid, not it is still 'unpaid'

Items 1 is clearly a bug fix whereas 2 & 3 are a bit borderline.

Item 2 is the fact that for pending contributions (in general) we don't create financial items when creating them. We do for (some) other
statuses. This was  discussed here https://github.com/civicrm/civicrm-dev-docs/issues/712#issuecomment-545164618 & the summary was
'it would be better to change this but this is what was the scope /how it is'

Item 3 is discussed in https://docs.civicrm.org/dev/en/latest/financial/financialentities/ with the summary  being that in any other path
to creating a partial payment the financial item would be left at 'Unpaid' - hopefully until it's fully paid.

Item 1 is a clear bug fix & I think the fact no-one picked it up is material because it gives us a clue as to how many
people use this rather obscure flow that requires an admin user to alter the status to 'partially  paid' and alter the amount.

Given the above we have a choice
1) Make this flow behave like other flows, despite this flow being arguably correct or
2) Hack away to keep the current quirks

I've come down on the side of 1 as a standardisation. I think changing it so items 2 & 3 behave differently is worth pursuing but it's better
for this edge case flow to do the same as our approved flow & if we want to iterate on that we can