APM service operation callbacks block receive loop on duplex transports

Similar to issue #4946, the callback passed to `BeginOperation(callback, state)` is called from the thread which is responsible for fetching the next incoming message in a loop. If you block that callback thread, you prevent any other calls from completing. In the following code, the inner callback won't get called until the `Thread.Sleep` completes.

```c#
channel.BeginDoWork(ar =>
{
channel.EndDoWork(ar);
channel.BeginDoWork(ar2 =>
{
channel.EndDoWork(ar2);
}, null);
Thread.Sleep(60000);
}, null);
```

This is NOT a regression from .NET Framework, it exhibits the same behavior. I consider this to be incorrect behavior which. Fixing this will have 2 performance effects. A single request will take slightly longer to execute as the callback will need to be executed on a different thread. It will also mean concurrent calls, or subsequent calls made from within the callback will complete slightly faster if their reply is already available as dispatching a second reply can then happen while the first callback is still executing. So you'll get slightly slower performance with no load, and better latency with high load.

This isn't urgent as it's existing behavior on .NET Framework and not a regression.

Start by tracing the APM BeginOperation(callback, state) dispatch path and the receive loop for duplex transports, using the nested BeginDoWork example as the reproducer. Compare the behavior with issue #4946 and determine how callback execution should be separated from message fetching. Done means a blocking callback no longer prevents a nested or concurrent reply from being dispatched, with regression coverage for this scenario.

Written by the indexing model from the issue text.