client: expose a method to create a trace client to replace the delegated tracer

[jsternberg]

This change removes the delegated tracer and replaces it with exposing
a method to create the trace client.

The primary benefit is it separates a client functionality from server
functionality. The delegation was only used by clients and it would
often happen automatically. If you initialized a client, it would
potentially report the same traces multiple times.

For the detect functionality, it was possible to turn off delegation on
the clients by enabling tracing or metrics from there. This prevents the
detect functionality from conflicting with the client delegation so it
always works properly now.

It also refactors the delegated span exporter a bit so its usage is not
tied to the detect.Exporter() method. It also only delegates to a
single span exporter which should help prevent accidentally sending
traces multiple times to the same client.

Clients are expected to use the new method and register a separate span
processor rather than use the tracer delegate.

[tonistiigi]

PTAL CI errors.

The downside of this seems to be that it is missing the buffer. By the time TraceClient() gets called some traces have already been written.

[jsternberg]

I need to do a buildx companion PR for this before this gets merged, but I've updated this to the point where it now mostly works as I intended it to.

The delegated span exporter isn't gone, but it's been moved out of the detect package to become more explicit. My vision for the detect package is it is similar to autoexport. For the initialization of the tracer and meter providers, I think that should go in application code rather than be automatically done in detect.

So the delegated span exporter is there but with a few modifications. First, it's initialized and passed to the initialization of the OTEL tracer during initialization. Second, the span exporter only allows one delegated span exporter. This was done to avoid having situations where we send a trace multiple times due to an accident. It also prevents the span exporter from having to store the initial buffer of traces forever.

The resolve client then sets the span exporter directly on the delegated span exporter. It does not try to access the tracer.

I think this should end up making this code path a bit more clear.