Duplicate activations for auto-started orchestrations

It appears that the session manager in DurableTask.AzureStorage can under some circumstances create duplicate activations, when using auto-started orchestrations.

The reason is that inside `AddMessageToPendingOrchestration`, when sending a timer-fired event to an existing instance, there is a check to see if the currently active instance has a matching execution id. If not, the messages are put into a new batch.

Even if we don't care about whether this timer is delivered (it would be o.k. semantically to not deliver it), the fact that there is now a separate batch is a problem for our entity implementation because this new batch causes a new, second instance of the same entity to be started, which means we lose state/operations.

A possible solution would be to modify the semantics of timer/event delivery *just for auto-started instances* so that the execution id is ignored.