Deduplicate Command/Request/Event pipeline builders

_Filed from an automated code-quality analysis. Verified against source._

## Problem
Three pipeline-builder classes implement the same component-list + reverse-fold `Build()` algorithm, differing only in the middleware-delegate type. The implementations have also drifted: `CommandPipelineBuilder` exposes `Use(int index)`, `Remove`, `RemoveAt`, `Clear`; the other two do not — a diverging API for an identical concept.

## Locations
- `src/Elsa/Mediator/Core/Middleware/CommandPipelineBuilder.cs`
- `src/Elsa/Mediator/Core/Middleware/RequestPipelineBuilder.cs`
- `src/Elsa/Events/Core/Middleware/EventPipelineBuilder.cs`
- Shared engine already exists: `src/Elsa/Pipelines/Core/...`

## Severity / impact
Medium. Triple maintenance of one algorithm; API drift means bug fixes/features land in one builder but not the others.

## Proposed remedy
Introduce a generic `PipelineBuilder` in the Pipelines layer holding the component list and `Build()` loop, and have the three concrete builders derive from it (or be thin generic closings). Reconcile the public API so all three expose the same operations. Keep the existing interfaces (`ICommandPipelineBuilder`, etc.) for DI compatibility.

Read the three builders in src/Elsa/Mediator/Core/Middleware/CommandPipelineBuilder.cs, src/Elsa/Mediator/Core/Middleware/RequestPipelineBuilder.cs, and src/Elsa/Events/Core/Middleware/EventPipelineBuilder.cs, then inspect the shared engine under src/Elsa/Pipelines/Core/.... Compare their Build() algorithms and public operations. Done means the builders share a generic pipeline implementation, expose consistent operations, and retain the existing interfaces for DI compatibility.

Written by the indexing model from the issue text.