Fixes a race in destroyHandler w.r.t. dc.messages sync.Map

Motivation:

This PR is meant to fix a contributing factor to the following race PR: jjeffcaii/reactor-go#45

In the current implementation of destroyHandler - it's possible to call stopWithError on a callback that has already been unregistered. This can affect a completely unrelated Duplex object (because global pools are used for processor objects - and an already "disposed" processor can receive an error).

The race (for example) can occur between the following pieces of code:

They both access dc.messages. destroyHandler - for reading (iteration), onFinally - for writing (inside unregister method).

In the existing version of destroyHandler - by the time iteration (Range()) over dc.messages is complete - some of the messages may have already been unregistered and removed from the map. This is where the race comes from.

As per documentation: https://pkg.go.dev/sync#Map.Range

Range does not block other methods on the receiver

-> Meaning that it's totally safe to invoke every callback from inside Range - no need to store callbacks in a slice beforehand.

Modifications:

Perform callback stopWithError invocations directly during Range iteration, without creating a slice of callbacks beforehand.

Result:

The issue described in jjeffcaii/reactor-go#45 goes away.