Enrich `health.Pinger` to propagate OpenTelemetry context & support timeout

[xeger]

I would like to trace my clue health checks.

I would also like to bound the maximum time that any Ping will take so that I can use Checker to enforce a service-level objectives on maximum request duration without creating a thundering herd of overlapping pings that consume resources. (Basically: cancel the client context to release any server resources that are being held by "deep pings" to critical dependencies.)

Instrumenting health seems straightforward; see #586 for a proof of concept. My primary question is whether we should build OTel awareness into the health package, but given our go.mod already depends on it, seems harmless to do so.

Adding a timeout to pingers also seems easy; we could add an Option and trigger a context.WithTimeout when the option is provided.

[raphael]

Makes a lot of sense, thank you for bringing this up. Quick question: is there a reason we can't use the otelhttp transport to trace health checks?

[xeger]

Great idea. I also realized there's already a WithTimeout option that applies on the client level, so nothing needed there.

See updated PR w/ tests. We default to an otelhttp.NewTransport but add a WithTransport option in case the caller needs something else, or needs to add otel transport options of their own.

[xeger]

I also needed to add SpanContext propagation to Checker, so I took the opportunity to add child spans for every registered pinger.

I upgraded to the latest Open Telemetry suite and also to semconv 1.34.0 as part of this work, in order to facilitate or really, force) upgrades among our clients.

See #586