fix(otel): Overwrite "trace" context in Sentry error

[tonyo]

This patches the following issue: when creating a transaction in the span processor, we later overwrite its SpanID/TraceID. The problem is, the trace context is also set on the scope when the span is started:

sentry-go/tracing.go

Line 176 in f03b31a

hubFromContext(ctx).Scope().SetContext("trace", span.traceContext().Map())

...which leads to broken error-transaction linking.

So ultimately we need to either/or:

1. Pass additional SpanOptions to StartTransaction that set the right SpanID/TraceID right away
2. Overwrite the trace context later.

Here I'm taking approach 2 because it's easier, but generally speaking I believe we should review setting trace context (and a few other tracing related things) on the scope.

[codecov]

Codecov Report

Base: 79.08% // Head: 78.98% // Decreases project coverage by -0.10% ⚠️

Coverage data is based on head (975424e) compared to base (7de80f2).
Patch coverage: 40.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #580      +/-   ##
==========================================
- Coverage   79.08%   78.98%   -0.10%     
==========================================
  Files          38       38              
  Lines        3859     3860       +1     
==========================================
- Hits         3052     3049       -3     
- Misses        705      708       +3     
- Partials      102      103       +1     

Impacted Files	Coverage Δ
otel/event_processor.go	58.33% <40.00%> (-28.63%)	⬇️
stacktrace.go	83.65% <0.00%> (+1.44%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[cleptric]

https://github.com/getsentry/sentry-go/blob/master/scope.go#L359-L374

Let's remove the logic in StartSpan and set the trace context in scope.ApplyToEvent() instead.

[tonyo]

@cleptric Not entirely sure what you're suggesting, but it sounds larger/riskier than what was initially planned for this PR. Can you open an issue and explain your idea there please?
And this PR will at least fix things for specific OTel use case.