Add new use cases to the membership bounded context that represent different state change actions:
* Mark a membership as moderated or unmoderated.
* Soft-delete a membership or remove soft-delete status
Implementation notes:
The currrent implementation (mis)uses a single field for moderation and deletion - `status` by applying binary flags. The new implementation must provide a new, more high-level API that hides the storage details:
* The new implement`MembershipApplication should encapsulate this behavior` domain class should get `markAsDeleted`, but must provide a new`removeDeletionMarker`, more high-level API - use cases where each of the actions is separate and the storage is a detail, abstracted away in the data model. When we change the database implementation`markAsModerationNeeded` and `markAsApproved` methods (naming at your discretion).
* The `DoctrineMembershipApplicationRepository` is responsible calculate the new `status` value
This architecture will allow us to replace the database implementation without touching the domain model, we will use separate fields in separate tablescases or controllers.
The logic for changing the status in the Fundraising Operation Center is in `app/model/Member.php` and `app/controllers/Backend/Ajax/MemberController.php`. It's completely untested, so the recommended approach would be to extract the code from the controller into the use cases nearly 1:1, achieve 100% coverage with new tests and then refactor the extracted code.