chore: SpanBuilder API cleanup

[scottgerring]

Parent issue for all of the API cleanup involved with SpanBuilder. As this is mostly going to be coordination (e.g., with tokio-tracing) to confirm we can do it, we should probably track it, and do the actual code changes, in one big hit.

[scottgerring]

I don't think this makes sense until #2420 , and the associated PoC #1571 , have been done:

• These APIs can't really be changed until a path away from them for tokio-tracing is provided
• Where the tokio-tracing/OTel integration lands, and how it looks, determines whether or not the existing integration needs to be changed to do this.

If we land on something that extends Björns PoC for instance and everyone agrees to move towards that, then this dependency will disappear itself. If we don't, the existing integration will need to be changed.

[bantonsson]

@cijothomas All the fields in the SpanBuilder are declared pub, so only removing the API calls doesn't really do that much. Should we make the internals private as well?

The builder is consumed in another create opentelemetry_sdk, so hiding things becomes convoluted. I'll just remove the methods and fields in question.

[bantonsson]

@cijothomas The circular dependency between opentelemetry-appender-tracing -> tracing-opentelemetry -> opentelemetry-sdk makes it impossible to clean this up without having a in-between release of tracing-opentelemetry. I'll try to ensure that we don't miss anything and do that dance.