Adds synchronous and asynchronous OpenTelemetry metrics

[jahough]

Problem Statement:

otelpgx, as of today, is only responsible for tracing observability.
Clients of pgx and otelpgx are forced to manage their own metric observability which can lead to:

• Redundancy
• Lesser granularity
• Potentially varying degrees of non-uniformity across a system using pgx because of implementation redundancy

---

Currently, PR #18 exists to add PGX Stats as Asynchronous Observable OpenTelemetry metrics.
This PR, while also instruments the same asynchronous metrics, aims to do so with a few changes and alongside additional features:

• Instrumenting synchronous metrics
  • PGX Operation Duration
  • PGX Operation Errors
• Stronger adherence to OpenTelemetry's Semantic Conventions overall guidance for DB clients
  • Metric and Attribute names have been updated to use the semantic convention where possible
  • Spans: https://opentelemetry.io/docs/specs/semconv/database/database-spans/
  • Metrics: https://opentelemetry.io/docs/specs/semconv/database/database-metrics/

This PR also implicitly resolves issue #40.

---

PR #18 seems to have left off awaiting information for how to have OTLP metrics scraped by Prometheus.
Those instructions, at least to me, seem outside the scope of otelpgx since that is more infrastructure-setup specifics, which OpenTelemetry-ecosystem tends to be agnostic to, and could become a chore to maintain long-term.
Because of that, I haven't included any specifics in the README as part of this PR; though if felt strongly otherwise, I can of course do so.

In my own environment (Application -> Collector <- Prometheus), I am able to verify metrics being reported.
See attached screenshots:

Screenshots

[obitech]

Thanks a lot for this comprehensive MR 🥳
In general it looks good, just a couple nits.

[obitech]

Could we expand the error messages a bit?

Suggested change

	return err
	return fmt.Errorf("create %s: %w", pgxPoolAcquireCount, err)

[jahough]

Good call! Updated

[obitech]

I'm not so familiar with the best practices around metric naming here, but would it make sense to add the base unit?

Suggested change

	pgxPoolAcquireDuration = "pgxpool.acquire_duration"
	pgxPoolAcquireDuration = "pgxpool.acquire_duration_seconds"

[jahough]

As long as each metric specifies their unit upon creation, we shouldn't need to include them in the metric name ourselves.
https://opentelemetry.io/docs/specs/semconv/general/metrics/#units

To this end, I did realize I missed specifying the unit in the async. metric pgxPoolAcquireDuration in meter.go. This has now been fixed.

FWIW as well-- Depending on users' observability stack and its own configuration, it is possible for the metric unit to be added to the metric name later on.
Using Prometheus as an example, it will append _milliseconds_bucket to the metric name db_client_operation_duration.

otelpgx/tracer.go

Line 136 in f84cbc7

metric.WithUnit("ms"),