better handling of callbacks that might throw in CallbackStack

[samspills]

Capturing @durban's question here: #3973 (comment)
And also @armanbilge: #3943 (comment)

I think we're all agreed that the remaining callbacks shouldn't just be abandoned, and when talking it through with Arman he had a proposed refactor:

if CallbackStack encounters a throwing callback, it can install the current/next node as the head in the finally and then let the throw continue
this leaves it up to the caller to decide what they want to do
if they're cool with the exception and want to invoke the rest of the callbacks, they can just call apply again
if they want to tear down, maybe we can bring back clear for this

[djspiewak]

We should probably be pretty careful here. Any performance hit at all as a consequence of this is not worth it, since we know a priori that none of our internal callbacks will throw, and CallbackStack is strictly internal. If we can do it without any performance hit though, it would be nice to not make unnecessary assumptions.