Coalesce concurrent statement preparation

[bikeshedder]

Rework the statement cache so that many tasks racing to prepare the same statement no longer each send a redundant, expensive PREPARE to the database. Each cache entry is now a tokio::sync::OnceCell: the first caller runs the preparation while the others wait for it, and if that caller fails or is cancelled, one of the waiters takes over. A failed preparation leaves the cell uninitialized, so the next caller simply retries.

The cells are held behind an Arc, which matters for eviction. A preparation in flight keeps working on its own cell, so a clear() or remove() landing mid-flight detaches that cell from the map instead of being silently undone once the preparation completes. Resurrecting an entry that way would defeat the very purpose of StatementCaches::remove(), which exists to drop statements that went stale.

The map lives in a StatementCacheInner<V>, with StatementCache as a thin StatementCacheInner<Statement> wrapper. The value type is generic purely as a test seam, not as a claim to reusability: Statement has no public constructor, so without it every test would need a live database. With it the interesting behaviour is covered by unit tests — coalescing to a single preparation under 128 concurrent tasks, eviction during preparation, size accounting against uninitialized cells, borrowed/owned key matching, and clear.

Based on the approach in #422 by @tgeoghegan.

[tgeoghegan]

For whatever it's worth: this LGTM, and with much better test coverage than I achieved in #422.

[bikeshedder]

This is my first AI assisted code change of Deadpool.

While writing the tests for it the Agent even found a real resource leak in tokio-postgres:

• fix: don't leak server-side state when a future is cancelled rust-postgres/rust-postgres#1374

I'm just updating the CHANGELOG and will merge this shortly.