chore: Add async support classes for concurrency and HTTP transport

[jsonbailey]

What

Adds the async support classes the async SDK is built on, under ldclient/impl/aio/. Pure-additive: the package is dormant until its first consumer lands in a later slice, so it adds no runtime surface to main beyond the new (as-yet-unimported) modules.

• aio/concurrency.py — async concurrency primitives: AsyncEvent, AsyncLock, AsyncQueue, AsyncRepeatingTask, AsyncWorkerPool, AsyncTaskRunner, AsyncCallbackScheduler, and spawn_handle/join_handle. Each wraps a piece of fiddly asyncio plumbing (timeout-aware waits, queue exception normalization, an interval-from-start repeating task, a bounded task pool) that async callers would otherwise inline repeatedly.
• aio/transport.py — async HTTP/SSE transport (AsyncHTTPTransport, AsyncSSEFactory, make_client_session) over aiohttp.
• aio/transport_types.py — the shared TransportResponse.
• testing/test_aio.py — unit tests for the above (they previously shipped untested).
• pyproject.toml — the async packaging these need: the [async] aiohttp extra plus aiohttp / pytest-asyncio dev deps and asyncio_mode="strict" (the tests run under pytest-asyncio, so CI can't pass without it).

Why

Foundation for the async Python SDK (epic SDK-60). These are genuine async support classes, not a compatibility shim: there is no sync twin — the sync code uses the equivalent stdlib/SDK primitives (threading, queue.Queue, RepeatingTask, FixedThreadPool, urllib3) directly.

Consumed by later slices: concurrency.py first by async big segments and the async flag tracker, then the event processor, data sources, and data systems; transport.py first by async FDv1 streaming/polling, then the event processor and FDv2 sources.

Validation

• uv run pytest ldclient/testing/test_aio.py — 28 passed
• uv run mypy ldclient — clean
• isort / pycodestyle — clean

Refs SDK-2601 (epic SDK-60).