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.

Start by reading the linked cross-SDK middleware specification and .NET user guide, then inspect the durable worker/builder APIs in this Java SDK. Use the proposed orchestration and activity middleware entry points to map the design, including context features and validation rules. Done means the listed acceptance tests, documentation, and host-feature integration are implemented without wire or protobuf changes.