New Performance API Wishlist

[adinauer]

Description

This issue shall serve as a sort of wishlist where we can collect ideas for the new Performance API.

If you have anything you'd like us to improve when reworking our Performance API in the Java SDK, please do leave a comment.

Here's some ideas:

• Get rid of transaction, only have spans in the API (note, depending on when we rewrite the API, the Sentry UI in product will likely still have transactions but the Java SDK API will not have those anymore)
• Have spans added to the scope by default (this may not apply to Android due to globalHubMode)
• Make it easier to continue a trace (Sentry.continueTrace -> Sentry.startTransaction is more complicated than it needs to be)
• Consider moving to something like a Propagator design that OpenTelemetry has for extracting and injecting tracing information
• Merge different objects used for tracing information (PropagationContext, TransactionContext/SpanContext, Baggage, TraceContext)
• Have the span implement AutoClosable so it can be used in try with resources statements and have the span finished automatically
• Align attributes / data closer to OpenTelemetry (this may mean limited support for data types)

NOTE: A reworked Performance API will likely be a breaking change where we completely remove the old API as it will likely be very hard (if not impossible) to make them coexist. So we can use this as an opportunity to clean up.

[thinkocapo]

I request feature parity with other SDK's that have already made the transition to the Spans Only model. And documentation parity.

[adinauer]

Baggage storing everything as String might not be ideal and requires workarounds like #4279 where we now store certain values directly in its most used type to avoid performance problems.

We should check if there's a way to avoid this.