[SDT-0002]: move ServiceContext from SSC to SDT implementation

[kukushechkin]

Move ServiceContext from swift-service-context as Instrumentation.InstrumentationContext. Implements SDT-0002, companion to apple/swift-service-context#92.

Motivation:

ServiceContext lived in its own package mainly for swift-distributed-tracing users, adding release overhead for little benefit. The name also reads as server-specific, discouraging non-server adoption.

Modifications:

• Moved ServiceContext to Instrumentation.
• Renamed ServiceContext/ServiceContextKey/AnyServiceContextKey to InstrumentationContext/InstrumentationContextKey/AnyInstrumentationContextKey, keeping deprecated typealiases for old symbols.

Result:

Existing code keeps compiling unchanged. Direct dependents using the old names get a deprecation warning with a fix-it; swift-service-context dependents get none, by design.

diagnose-api-breaking-changes reports breaking changes across Tracing/Instrumentation/InMemoryTracing, all "type changed to Instrumentation.InstrumentationContext". This is expected — typealiases are transparent to the type system, so this shows up no matter which name call sites use, and we don't target ABI stability here, only source-compatibility.

[czechboy0]

Did we consider putting the new types into one of the existing modules? Why do we want it in a separate one?

[heckj]

@kukushechkin would you mind tacking on ContextStorage to the .spi.yaml as well, so that this module is included in SPI's documentation rendering.

diff --git a/.spi.yml b/.spi.yml
index 26f45b2..ea570cd 100644
--- a/.spi.yml
+++ b/.spi.yml
@@ -1,4 +1,4 @@
 version: 1
 builder:
   configs:
-    - documentation_targets: [Tracing, Instrumentation, InMemoryTracing]
+    - documentation_targets: [Tracing, Instrumentation, InMemoryTracing, ContextStorage]

[kukushechkin]

Did we consider putting the new types into one of the existing modules? Why do we want it in a separate one?

@czechboy0 no, did not think about it. It feels it should be in a separate module. What is the downside of have a new module?

[czechboy0]

Did we consider putting the new types into one of the existing modules? Why do we want it in a separate one?

@czechboy0 no, did not think about it. It feels it should be in a separate module. What is the downside of have a new module?

I feel that the default should be not to separate into a separate module, unless we have a good reason. Do we?

[slashmo]

Did we consider putting the new types into one of the existing modules? Why do we want it in a separate one?

I agree with Honza to put it in Tracing given it's now called TracingContext. If we change our mind down the line it's easy to split out TracingContext into a new target using exported imports. However, moving from two targets back to one is a bit more complex. I'd lean towards not adding the separate target unless we have a use-case outside the Tracing target.

[kukushechkin]

@czechboy0 @slashmo Tracing <-> TracingContext, I see the point. Will do.

UPD. Ah, wait, no, Instrumentation depends on ContextStorage. And Tracing depends on Instrumentation. Moving TracingContext to Tracing will create a circular dependency.

[slashmo]

Hm, yeah. We need it for the context propagation requirement of Instrument. In that case I'd put it in Instrumentation directly rather than ContextStorage. That being said, should it be called InstrumentationContext instead of TracingContext then?

[kukushechkin]

Hm, yeah. We need it for the context propagation requirement of Instrument. In that case I'd put it in Instrumentation directly rather than ContextStorage. That being said, should it be called InstrumentationContext instead of TracingContext then?

Also works. @czechboy0 wdyt?

[czechboy0]

Works for me.

[ktoso]

Sounds fine to me, while keeping a typealias for compatibility I guess right?

[czechboy0]

One last docs fix, otherwise lgtm