refactor: merge contribution data into same table

[wpf500]

This is a fairly major refactor (rewrite?) of the contribution code.

There are lots of problems with the contribution logic at the moment:

• The data is split between the Contact model (contribution* fields) and ContactContribution. This indicates poor logical separation and means some contribution code ends up being in ContactsService when it shouldn't be.
• Contact.contributionType and ContactContribution.method largely overlap (e.g. a Stripe payment method is always an automatic contribution, etc.)
• Each Contact only has one ContactContribution, so changes are overwritten and there's no history of a contact's payment IDs. This is especially problematic for contributions that have pending changes (e.g. a non-prorated annual change), as we can loose the ID for a current subscription or mandate
  • ContactContribution.nextAmount attempts to solve this in a very ugly way
• The various PaymentProvider implementations have to manage a lot of the logic of how things are stored in ContactContribution and there's a lot of duplication
• Manual contributions are handled differently to Stripe or GoCardless ones, we currently have a very ugly ContactsService.forceUpdateContactContribution method to allow updating them

This PR introduces a many-to-one relationship between ContactContribution and Contact, and a ContactContribution.status field to differentiate between versions. The status can be pending, current or NULL, there can only ever be one current or pending ContactContribution.

[wpf500]

Closing as moved to beabee-communityrm/monorepo#42