Add Durable Task middleware support

Summary

Track adding SDK-level Durable Task middleware support to the Python SDK, aligned with the .NET reference implementation.

Reference spec: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/cross-sdk-middleware.md
.NET user guide: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/durable-task-middleware.md
Motivation: https://github.com/Azure/azure-functions-durable-extension/issues/3054

The spec may shift until the .NET v1 implementation is merged. This issue is intended to track the Python design and implementation work so it can follow the same durable middleware contract with idiomatic API names.

Proposed shape

Names are illustrative, not final API commitments.

@app.orchestration_middleware
async def orchestration_middleware(ctx, next):
    if not ctx.is_replaying:
        ctx.logger.info("starting orchestration", extra={"instance_id": ctx.instance_id})

    await next(ctx)

@app.activity_middleware
async def activity_middleware(ctx, next):
    cached = await cache.try_get(ctx.name, ctx.input)
    if cached is not None:
        ctx.set_result(cached)
        return

    await next(ctx)

Design points to cover

• Decorator and/or builder registration APIs that are scoped to a worker/app instance.
• Registration ordering: first registered middleware runs outermost and unwinds last.
• Dataclass/protocol-style contexts that expose durable task name, instance ID, version/parent/tags where available, input, raw input where available, replay state for orchestrations, features, and result after next.
• A feature collection using type keys or well-known keys when runtime type identity is not the right Python abstraction.
• Orchestration middleware determinism guidance for replay, including replay-safe logging and avoiding datetime.now, uuid.uuid4, random, file/network I/O, arbitrary asyncio awaits, and mutable process state.
• Activity middleware short-circuiting through an explicit set_result API.
• Host integration pattern for Azure Functions or other hosts to attach invocation context through features instead of durable middleware depending on host middleware internals.

Acceptance criteria

• Orchestration and activity middleware APIs are exposed at the durable worker/app level.
• Middleware executes in registration order and unwinds in reverse order.
• Orchestration middleware must call next(ctx) exactly once when completing successfully; missing or duplicate calls are rejected where feasible.
• Activity middleware can call next(ctx) once or short-circuit only through ctx.set_result(...); duplicate next is invalid.
• Host-specific objects can be passed through features without serialization into durable history.
• Documentation covers replay determinism and the difference between durable middleware and host/Functions middleware.
• Tests cover registration ordering, context population, feature access, orchestration next-call validation, and activity short-circuiting.
• No wire protocol or protobuf changes are required.
• Entity middleware is out of scope for v1.

Comece comparando a .NET cross-SDK middleware specification e o user guide referenciados e, em seguida, localize os Python durable worker/app registration entry points. Defina as orchestration e activity APIs, os contexts, o feature access, o ordering, a validação e o comportamento de short-circuit, e adicione os testes e a documentação dos critérios de aceitação; entity middleware e alterações de wire estão fora do escopo.