TL;DR: This PR Adds Sentry.updateSpanName() to reliably update span names in OpenTelemetry environments; prevents overwrites from both OpenTelemetry HTTP instrumentation and Sentry's span inference logic; preserves custom names by marking them with 'custom' source and storing in temp field which takes precedence over the actual name and gets deleted at the end

"Why not use span.updateName()?", the avid SDK user might ask. Here's why:

In our Node SDK, most/all spans are created by OpenTelemetry instrumentation. OpenTelemetry has no concept of a transaction source and only stores the name of the span in the Span instance. Some instrumentation, most importantly, @opentelemetry/instrumentation-http starts a span (in this case root span) and later on updates the name. In the http case, this update happens at the end of the request lifecycle. Consequently, any span name updates prior to this call, regardless of them coming from our SDK or from users, are overwritten.

In addition to this limitation within Otel instrumentation, we also have our own span name, op and source inference logic which we apply when exporting the span to add Sentry-specific data (like a better span name, an op, a transaction source and additional data) to otel-generated spans. So even if Otel didn't call updateName() in its instrumentation, user-made updateName calls to e.g. http.server spans were also overwritten by our logic.

So we need some way of 1. bypassing our span inference logic and 2. ensuring a user-update span name has precedence over otel's span name updates.

1 we can achieve with setting the source attribute to custom and ensuring we don't change the span name if we encounter a custom source.
2 we can only achieve if we write the user-updated span name to temporary field on the span and apply it during our span name processing logic.

This is exactly what updateSpanName does:

• update the span name via span.updateName()
• add SEMANTIC_ATTRIBUTES_SENTRY_SOURCE: 'custom to the span
• add a temporary attribute with the provided name to the span

Further changes in this PR:

• Ensure we use the span name from temporary attribute if provided in parseSpanDescription
• Ensure we respect source custom in parseSpanDescription
• Delete the temporary attribute when creating the transaction envelope (no need to send this)
• Add a bunch of unit and integration tests for the newly added function.
• Also add two unit tests showing that span.updateName has no effect on http.server spans, even if you set source custom

This PR supersedes #14280 where I thought we could monkey-patch span.updateName directly to make updating the span name AND the source more consistent without a new top-level function. Turns out, we cannot do this because then, Otel instrumentation would also call the monkey-patched version of updateName, meaning we can no longer distinguish between user-made and otel-made span name updates.