Create support for "abortable events" in the framework, to deal with cases where the holding component is destroyed

This requirement was raised by FLUID-5332. A difficult form of race condition can emerge where a component holding an event or a listener is destroyed as a result of servicing one of the listeners. A clean solution to this issue would involve being able to formally abort the processing of a listener queue when the component holding its event is destroyed partway through the process. This is similar to the "preventable events" system that we still retain in outline, but is signalled by collateral action around the component tree rather than specific knowledge held within a listener as signalled by its return value.

This kind of race should not really occur in practice, but is unfortunately at a much greater risk as a result of our current renderer implementation which causes large-scale destruction of segments of the component trees that it manages whenever re-rendering occurs.

This implementation will interact well with our upcoming asynchronous models for communicating failure, when these are configured to do so by propagating a "ball of fire" up the component tree destroying components. In this case it is highly appropriate to abort any further listener notifications that are in progress when the error occurs - this is consistent with the standard semantics for "failed promises", not to say the analogous monadic model.