Add `diagnostics_channel` support for query and connection lifecycle events

La issue nomina pg e pg-pool, ma non include file di implementazione né test. Inizia esaminando la strumentazione IITM/RITM esistente e il pattern TracingChannel di undici; una proposta concreta deve definire i nomi dei canali, le strutture dei payload e la compatibilità con le versioni di Node prima che l'implementazione possa essere considerata completata.

I'd like to propose adding first-class TracingChannel support to pg and pg-pool, following the pattern established by undici in Node.js core.

TracingChannel is a higher-level API built on top of diagnostics_channel, specifically designed for tracing async operations. It provides structured lifecycle channels (start, end, error, asyncStart, asyncEnd) and handles async context propagation correctly, which was the missing piece that makes existing monkey-patching approaches fragile in real-world async Node.js applications.

Current instrumentation's today use IITM (import-in-the-middle) for ESM and RITM for CJS which has a few fragility concerns in today's ecosystem state, a few issues we have today:

• Runtime lock-in: both RITM and IITM rely on Node.js-specific module loader internals (Module._resolveFilename, module.register()). They don't work on Bun or Deno, which implement the Node.js API surface but not the module loader internals.
• ESM fragility: IITM is built on Node.js's module customization hooks, which are still evolving and have been a persistent source of breakage in the OTEL JS ecosystem.
• Initialization ordering: both require instrumentation to be set up before pg is first require()'d. Get the order wrong and instrumentation silently does nothing, which is very hard to debug in production.
• Bundling and Externalization: Users have to ensure their instrumented modules are externalized, which is becoming very difficult to guarantee with more and more frameworks bundling the server-side code into single executables, binaries or deployment files.

If pg emits structured events through TracingChannel, instrumentation libraries become subscribers, not patches. Each tool listens independently with no ordering concern, no clobbering, and no internal API dependency.

Before putting together a concrete proposal and PR, wanted to check: is there appetite for this? Happy to spec out channel names, payload shapes, and Node version compatibility considerations if so.