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 更改，即表示完成。