[Workflow] Describe the nuanced behaviour of how external events are allocated

**What content needs to be created or modified?**

cc @cgillum @kaibocai

There is a particular nuance in Dapr Workflows (and Azure Durable Functions too) which leads people to believe that when the code is awaiting multiple external event Tasks in a **when any** pattern, once a single Task has been completed and a **winner** has been determined, then the non-winning task won't consume an event.

This is not true. The non-winning Task will continue to consume an event if such a matching event was to be raised throughout the life of the workflow instance, even though the workflow has advanced beyond the initial **when any**.

This problem is particularly evident when waiting for the same event (same event name) in a loop, [here is an example an individual suspecting this is a bug, however it is not.](https://github.com/dapr/java-sdk/issues/967) - It's worth adding that this issue was created off the back of a user on [Discord](https://discord.com/channels/778680217417809931/1075836407156850698/1179069570733052044) relaying their concern.

The guidance should be to use an Eternal Workflow pattern with `ContinueAsNew`, as this will remove any incomplete tasks and ensure that tasks are allocated correctly.

**Describe the solution you'd like**

Better docs to outline the above problem. The problem is almost touched on [here](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-features-concepts/#infinite-loops-and-eternal-workflows), but this particular nuance is missed

**Where should the new material be placed?**

possibly [here](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-features-concepts/#infinite-loops-and-eternal-workflows)

**The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos**