[flags] complications with deleting event

The Deleting event in the flarum/flags extension was refactored here https://github.com/flarum/flags/pull/35.

As a consequence:

- We cannot listen to the Deleting event and send anything back to the user because the flags for the post haven't been actually deleted yet.
- We cannot use the `afterDelete` callback from the `AbstractModel` because deletion is executed from the eloquent relationship, which uses an underlying query Builder object which doesn't fire events.

In addition, the original comment made by Ian (https://github.com/flarum/flags/pull/35#discussion_r563206641) - to me - isn't really, entirely valid. Our flags implementation dismisses all flags from a post when the flag(s) on that post are reviewed; it is one interaction that causes the dismissal of all flags of one post.

As such we need to remedy this by doing:

- Reinstate or move logic from `FlagsWillBeDeleted` to `Deleting`.
- Or fire a `FlagsHaveBeenDeleted` event.
- Use the post as argument in the event, not the flags (which are deleted).

Start by reading the FlagsWillBeDeleted and Deleting events, the AbstractModel afterDelete callback, and the relationship-based query Builder deletion described in the issue. Determine which event design preserves the post context and fires at the required point, then verify that the resulting event can support the flags dismissal interaction.

Written by the indexing model from the issue text.