Allow a Broadcaster to have one "Primary" listener, and potentially many secondary Listeners. The primary listener is guaranteed to run the DoOnRemoval first, and only when that is complete will secondary Listeners receive the event.
Prior to Ismail's addition of the notion of a "Secondary" listener, you could only safely observe process events from the Listener you passed in to the Process creation. That was because the act of pulling the process event off the event queue triggered the change of the public state of the process (thus keeping the event stream and the state in sync).
Ismail added a privileged "shadow listener" that could also be informed of the event. That wasn't quite the right model, however, because the real singleton is the primary listener.
That's what this patch implements.
This isn't quite the full solution for the Process Listener. The goal is that the primary Process Listener not only gets to drive the event stream, but that the primary listener gets to react to each event before any other Listener can hear about it. That will allow the process execution logic to run before any other agent gets a chance to change the process state out from under it. For that, I'll need to add a receipt mechanism to the event delivery, and have the forwarding to the pending listeners happen only after the receipt is acknowledged. But that will be a follow on patch.
I wonder if it might be better to add a new element to the enum, something like eBroadcastBitAll = eBroadcastBitStageChanged | ... | eBroadcastBitStructuredData,.
If we have to add a new element to this enumeration, I'm not sure everyone will realize that g_all_event_bits needs to be updated in a separate file (even though it's right below the enum definition).