Avoid unnecessary heap allocation in NewSpanStartConfig

[bogdandrutu]

Problem Statement

Right now calling NewSpanStartConfig will heap allocate SpanConfig every time is called.

Proposed Solution

Multiple solutions can be implemented:

• Expose Apply in the Options interfaces (add another internal func to avoid extending it), so users will execute what NewSpanStartConfig does but with a var sc SpanConfig and pass the address to sc.
• Replace NewSpanStartConfig with a ResolveSpanConfig (or other suitable name) that accepts a pointer to SpanConfig so internally SpanConfig can be stack allocated and a pointer to sc can be passed to the resolve func.

Same applies to all configs.

[MrAlias]

From SIG meeting:

• We need to have a benchmark around this. It may not be worth while to change all options if they are not created in the hot-path.
• It might also be this is a "ghost" allocation that might be optimized away by the compiler in real-world use case. We should include a benchmark to ensure this makes sense.

[MrAlias]

Another proposed solution is to have the New* functions return a type itself not a pointer to the type.

[jmacd]

I agree and support the idea. There are many examples of the proposed solution already in the metric sdk, for example

// NewMeterConfig creates a new MeterConfig and applies
// all the given options.
func NewMeterConfig(opts ...MeterOption) MeterConfig {
	var config MeterConfig
	for _, o := range opts {
		o.applyMeter(&config)
	}
	return config
}

[MrAlias]

Merging #2212 will allow this issue to be resolved after the stable release. All changes will be to unexported interfaces.