Acceptance Criteria

• The domain objects for bank data payments 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 direct debit. All other payment methods may throw "Not implemented" logic exceptions for now.

Implementation Details

• Refactor BankData as needed, dropping the FreezableValueObject trait and creating a proper class that gets all dependencies through the constructor.
• Drop the legacy bank account and bank number data. We don't need to store those and can reproduce them (if needed for display/mailing purposes) through the kontocheck api.
• For data protection reasons, IBAN and BIC must be nullable properties, introducting an "anonymized" state. The constructor with nullable arguments. There should be a public static factory method with required arguments to ensure that we construct an initially valid direct debit payment ("new payments need data").