Add Durable Task middleware support

Summary

Track adding SDK-level Durable Task middleware support to the Java 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 Java 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.

workerBuilder.useOrchestrationMiddleware((ctx, next) -> {
    if (!ctx.isReplaying()) {
        logger.info("starting orchestration {}", ctx.getInstanceId());
    }

    return next.invoke(ctx);
});

workerBuilder.useActivityMiddleware((ctx, next) -> {
    Optional<Object> cached = cache.tryGet(ctx.getName(), ctx.getInput());
    if (cached.isPresent()) {
        ctx.setResult(cached.get());
        return CompletableFuture.completedFuture(null);
    }

    return next.invoke(ctx);
});

Design points to cover

• Builder-level registration APIs for orchestration and activity middleware.
• Registration ordering: first registered middleware runs outermost and unwinds last.
• Context interfaces 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 keyed by Class<T> or another type-safe Java abstraction.
• Integration with dependency injection frameworks where present, without requiring a particular DI container.
• Orchestration middleware determinism guidance for replay, including replay-safe logging and avoiding nondurable CompletableFuture/threading usage, wall-clock time, random values, file/network I/O, and mutable process state.
• Activity middleware short-circuiting through an explicit setResult 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/builder level.
• Middleware executes in registration order and unwinds in reverse order.
• Orchestration middleware must call next.invoke(ctx) exactly once when completing successfully; missing or duplicate calls are rejected where feasible.
• Activity middleware can call next.invoke(ctx) once or short-circuit only through ctx.setResult(...); 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.

先閱讀連結的跨 SDK 中介軟體規格和 .NET 使用者指南，然後檢查此 Java SDK 中的 durable worker/builder API。使用提議的 orchestration 和 activity 中介軟體進入點來對應設計，包括內容功能和驗證規則。實作列出的驗收測試、文件以及 host 功能整合，且不進行 wire 或 protobuf 變更，即表示完成。