Refactor client resiliency to use UnaryUnaryClientInterceptor

Centralize client failure tracking and channel-recreate triggering in a
`ClientResiliencyInterceptor` (sync) and `AsyncClientResiliencyInterceptor`
(async) instead of the per-call `_invoke_unary` indirection. This addresses
feedback [1/10] on PR #135: resiliency wiring now lives in one place and the
call sites read as normal stub calls.

- Add `ClientResiliencyInterceptor` and `AsyncClientResiliencyInterceptor`
  in `durabletask/internal/grpc_resiliency.py`.
- Switch `LONG_POLL_METHODS` and `is_client_transport_failure` to use full
  gRPC method paths (`/TaskHubSidecarService/...`) so the interceptor can
  match the `method` field on `ClientCallDetails` directly.
- Wire the resiliency interceptor into `TaskHubGrpcClient` and
  `AsyncTaskHubGrpcClient`: it is always prepended (defensive copy of any
  user interceptors) and re-applied on every channel recreate so all unary
  calls flow through it.
- Remove both `_invoke_unary` methods and revert all 34 call sites to
  ordinary `self._stub.MethodName(req)` (or `await ...` for async).
- Caller-owned channels (sync and async) deliberately bypass the resiliency
  interceptor since they are never recreated; this preserves the caller's
  exact channel reference and avoids `grpc.aio`'s lack of a public
  `intercept_channel` equivalent.
- Add test shims (`_ResilientSyncTestStub`/`_ResilientAsyncTestStub` plus
  `install_resilient_test_stubs`) so tests that patch
  `stubs.TaskHubSidecarServiceStub` with `MagicMock` still observe the
  failure-tracking pipeline.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: Bernd Verst