Move to Spans from unsafe pointers in the API

[czechboy0]

Summary

Applies the changes discussed in #32 (comment).

• Removed the Bytes struct in SpanID and TraceID that conformed to Collection, instead changed Bytes to be a typealias to a tuple of bytes.
• Refactored all the methods that used unsafe pointers in the API and moved them to Span/MutableSpan.
• Hit some limits on the current capabilities of nonescapable types, left a comment about future improvements.
• Removed TraceStateDecodingError and TraceParentDecodingError from public API.
• Updated all the implementations to use the new safe span APIs.

Test Plan

Adapted tests to the new implementation.

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 12 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
Sources/W3CTraceContext/SpanID.swift	89.36%	5 Missing ⚠️
Sources/W3CTraceContext/TraceID.swift	90.00%	5 Missing ⚠️
Sources/W3CTraceContext/Hex.swift	90.00%	2 Missing ⚠️

Files with missing lines	Coverage Δ
Sources/W3CTraceContext/TraceContext.swift	100.00% <100.00%> (ø)
Sources/W3CTraceContext/TraceState.swift	100.00% <100.00%> (ø)
Sources/W3CTraceContext/Hex.swift	92.00% <90.00%> (+1.09%)	⬆️
Sources/W3CTraceContext/SpanID.swift	90.90% <89.36%> (-9.10%)	⬇️
Sources/W3CTraceContext/TraceID.swift	91.37% <90.00%> (-8.63%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[czechboy0]

Moving to Span/MutableSpan would require bumping to Swift 6.2+. Let's discuss if that's what we want, or if we want to move back to unsafe pointers.