fix(cache): run sync handlers in the threadpool

[allen0099]

Closes #100.

Problem

@cache wraps every handler in an async wrapper, so FastAPI no longer sends a def handler to its threadpool. get_response() then called the sync handler inline, on the event loop, and blocking I/O in it stalled every other request on the worker.

The coroutine check also missed an object with an async def __call__, and a sync callable that returns a coroutine; both produced an un-awaited coroutine that then failed to encode.

Change

• get_response() awaits coroutine handlers and runs everything else with starlette.concurrency.run_in_threadpool.
• New _is_coroutine_callable(): inspect.iscoroutinefunction(func) (which already unwraps functools.partial), or the same check on type(func).__call__. A class counts as sync, because its type's __call__ is type.__call__.
• An awaitable result is awaited as a safety net.

A note on the issue text: a functools.partial of an async function was already handled, since inspect.iscoroutinefunction unwraps partials. It stays in the test as a regression case.

Tests

• test_sync_handler_runs_off_the_event_loop_thread records the thread ident of a sync handler and an async handler, and asserts they differ.
• test_handler_returning_a_coroutine_is_awaited is parametrized over a partial, an async __call__ object, and a sync function returning a coroutine.

Against the old get_response(), 3 of these 4 cases fail; the partial case passes.

Checks

• ruff check / format on fastapi_cachex, tests and scripts
• mypy strict on the package; mypy on tests and scripts
• pytest against live Redis and Memcached (CACHEX_REQUIRE_LIVE_SERVERS=1): 720 passed, 100% coverage
• zensical build --strict

The CHANGELOG entry sits at the top of ### Fixed, next to #133's, so whichever merges second needs a trivial rebase.