Allow an on_close handler without consuming the NotificationHandle

[taladar]

I am looking at a situation where I either want to close a persistent notification due to some external event or remove it from the list of notification handles if the user closes it manually. That seems impossible with the current API since on_close consumes the NotificationHandle which close() needs.

Alternatively it should at least be possible to tell if the notification was closed from a NotificationHandle so stale handles can be removed.

[nothingmuch]

Ran into the same issue trying to add snoozing support to Ianny (break reminder program).

I would like to detect manual closure and add an exponential back-off delay before re-displaying it, but as far as I can tell the only way to do that would be to remove all use of update and close, and only use rust_notify's timeout so that on_close becomes available.

The alternative idea of polling closure status instead of responding to a close action is actually better suited for my use case, because Ianny uses a notification handle that is (optionally) updated to display a progress bar. When closed manually, the next iteration of the loop update seems to re-create the notification.

A third alternative would be to add a timeout parameter in on_close (and presumably wait_for_action) and use this instead of sleeping in the update loop. This seems awkward since unless the return type changes, it would necessitate a timeout handler that has a different calling convention into which the handle can be moved.