Cascading restore

[marksalmon]

Hi Michael,

Thanks for the very useful package.

I note in the docs its says:

Note: It's important to know that when you cascade your soft deleted child records, there is no way to know which were deleted by the cascading operation, and which were deleted prior to that. This means that when you restore the blog post, the associated comments will not be.

Given that deleted_at is a timestamp, surely we can determine relations that were deleted as part of the cascaded soft delete if their deleted_at value is equal to (or greater than, just in case the operation takes a second) the parent model's deleted_at value.

This is how I implemented it in my app so I thought it might be worth a PR.

[michaeldyrynda]

Made a few small tweaks to the tests and merged in - thanks @marksalmon

[michaeldyrynda]

I've reverted this as it's not going to behave consistently or, ultimately, correctly.

The way that the deletes are executed via the deleting event, the Post will be the last record to be deleted, meaning that its timestamp is going to always be ahead of any children deleted as part of the cascade i.e. calling $post->restore() won't always restore all children reliably (maybe there are lots and even a second's difference will throw it out).

In the test scenario as written, this works because the cascade is effectively instant. However, if we elongate time (using Sleep::for(1)->second() between each delete, the test ends up failing.