Acceptance Criteria

• The domain objects are refactored according to the data model. You can leave other payment objects in a semi-broken state as long as all remaining tests still pass and the next steps are clear (i.e. putting TODOs/commented-out code in classes, skipping tests).
• The implementation of the PaymentRepository interface implements storing and retrieving payments with paypal. All other payment methods may throw "Not implemented" logic exceptions for now.
• The "data blob" (logging) part of the entity does not store firstName, lastName, email, and other PII (to avoid the need for anonymisation)

Implementation Details

• Refactor PayPalData as needed, dropping the FreezableValueObject trait and creating a proper readonly value object for the TransactionData implementation, with a similar pattern used as in the credit card modeling case.
• Add Doctrine mappings to the non-abstract implementation of the payment class