Replace OSAllocatedUnfairLock with Mutex

[ladd]

Summary

Migrates locking from os.OSAllocatedUnfairLock to Mutex from the Synchronization framework. This is a slight efficiency improvement (avoids an allocation), and wrapping the object is safer/clearer.

Where the lock guarded a single object, the Mutex now wraps that object directly:

• Baggage → Mutex<TelemetryAttributes?> (also resolves the prior "stored property is mutable" Swift 6 warning)
• Meter → Mutex<[Instrument]> (active instruments)
• Counter / ObservableCounter / ObservableUpDownCounter / ObservableGauge / Histogram / ExponentialHistogram → Mutex wrapping the instrument's values
• FlushTimer → Mutex<Bool> (suspended flag)
• StableGuidSampler → Mutex<Data> (GUID); the withLockUnchecked set path became a normal withLock
• ExampleReporter → static Mutex<Data?> (session GUID)

Span and Tracer guarded several heterogeneous fields (some read elsewhere without locking), so they keep a single mutex that also serializes those fields, preserving the prior single-lock semantics. Read-only computed accessors were added where the wrapped value was previously a directly-readable stored property, to avoid churning the exporter and test call sites.

Also adds public get accessors for span and attributes on Baggage, for better ergonomics in client code.

Test plan

• swift build — clean (only the pre-existing Baggage.span non-Sendable warning remains)
• swift test — all 92 tests pass
• Two tests that mutated through .values.reset() were updated to snapshotAndReset(), since values is now a read-only snapshot

@jparise
@bachand

[bachand]

LGTM with a few comments. Thanks @ladd!

[bachand]

What do you think about continuing to use OSAllocatedUnfairLock here and in other cases where the value is Void? I don't feel strongly, but the code did seem a bit cleaner without the _ ins. 🤔

[ladd]

I would ideally put the entire state storage inside the Mutex wrapper. I opted to save that for future refactor work.