Consider changing SoftDelete interface for DeleteOperation

I had a chat with @paulcsmith on this, and he brought up a good point:

... it can cause weird bugs where you’re not sure how to do a real delete, or if some other mixin/shard does something in delete except the record wasn’t actually deleted. It also gets confusing when team size gets bigger because new devs might not realize it’s doing a soft delete or know how to do a real delete. I think if “delete” does a real delete we could add before/after_soft_delete. That way you can trigger ones specifically for a real delete or a soft delete.

Right now, the DeleteOperation have the same interface between actually deleting something, and just "soft" deleting something. Just looking at the operation, you have no idea if the record will be really deleted or soft deleted. Even going to where the operation is ran, you still don't know. You would have to always go to the model.

We could add an additional method for soft delete models, and although the current callbacks do run for soft deletes, we could still add separate callbacks to make it clear that this isn't going to run your DB level cascade.

DeleteUser.soft_delete(user) do |o, u|
end

class DeleteUser < User::DeleteOperation
  after_soft_delete do |u|
    # bulk deletes don't actually work... just PoC
    DeletePosts.soft_delete(u.posts) do |o, p|
    end
  end
end

Start by locating DeleteOperation and the soft-delete model interface described in the issue, then trace where delete callbacks are defined and run. Compare the current real-delete and soft-delete paths, and clarify the proposed method and callback boundaries. The work is done when the interface clearly distinguishes both behaviors and their expected callback semantics are documented and tested.