.NET: [Feature]: Add expose WorkflowCompletedEvent, RequestHaltEvent and WorkflowFailedEvent

### Problem

When consuming workflow events via `WatchStreamAsync()` or `NewEvents`, there's no way to observe workflow completion or failure through the event stream. The framework emits `WorkflowStartedEvent` but has no corresponding `WorkflowCompletedEvent`. For errors, `WorkflowErrorEvent` exists but requires an `Exception` object .In scenarios where only an error message string is available (e.g., reading status from an external orchestrator), there's no suitable event type to use.

Additionally, `RequestHaltEvent` is internal, so implementations that need to surface halt information to stream consumers can't use it.

### Proposal

1. Add `WorkflowCompletedEvent`, a public event signaling that a workflow has completed, optionally carrying a result. This would be the natural counterpart to `WorkflowStartedEvent`.

2. Add a string based failure event (or overload `WorkflowErrorEvent`). Either a new `WorkflowFailedEvent` that accepts a `string errorMessage`, or an additional constructor on `WorkflowErrorEvent` that doesn't require an `Exception`. Not all failure scenarios have an exception object available.

3. Consider making `RequestHaltEvent` public with an `ExecutorId` property, so consumers can observe which executor requested a halt. Currently it's internal and filtered out of event streams.