Allow closing scopes out of order

Currently closing scopes out of order is disallowed in https://github.com/open-telemetry/opentelemetry-java/blob/3d5424a54ae6930e721e8c4813ad956047009394/context/src/main/java/io/opentelemetry/context/ThreadLocalContextStorage.java#L48 This poses a challenge when implementing instrumentation for Zio. Zio instrumentation is similar to what we have for kotlin coroutines. Every time a fiber is restored we activate otel context, when fiber is suspended we close the scope and remember the current context so that it could be activated when the fiber is restored again. The problem is that the user code executing in fibers can also activate scopes. Fiber could get suspended when user code has started the span and activated the scope but has not closed them yet. In such situation attempt to close our scope fails because it is not the current one. As a workaround we can run Context.root().makeCurrent() on suspend to avoid leaking scope to the thread that executed the fiber.
Kotlin coroutine instrumentation does not run into the same problem because there the programming model encourages users to keep the active scope in coroutine context so instead of context.makeCurrent() the user is expected to use withContext(context.asContextElement()) {...}.
As an alternative to allowing scopes to close out of order we could continue using Context.root().makeCurrent() to reset the scope or see if we can, similarly to kotlin coroutine instrumentation, let users keep scope in some zio fiber specific context. I don't particularly like the last option as it will surely create problems when fibers call instrumentations that expect to get the scope from the thread local.
If allowing closing scopes out of order is not desirable I'd welcome guidance on how such instrumentation should be implemented.

Start with ThreadLocalContextStorage.java at line 48 and read the Zio instrumentation context in PR 7980. The issue needs a maintainer decision between supporting out-of-order scope closure and retaining the root-context workaround; completion criteria are not defined in the issue.