camel-telemetry: fix trace context propagation for messaging components

[Croway]

Summary

• AbstractMessagingSpanDecorator used the default CamelHeadersSpanContextPropagationExtractor which only handles String-valued headers. Messaging transports like Kafka deliver headers as byte[], so trace context headers (e.g. traceparent) were silently dropped, breaking distributed trace propagation across services.
• Add CamelMessagingHeadersSpanContextPropagationExtractor that handles both String and byte[] headers, and override getExtractor() in AbstractMessagingSpanDecorator so all messaging components (Kafka, AMQP, SJMS, STOMP, Spring RabbitMQ, Azure Service Bus, etc.) benefit from the fix.
• The issue was discovered while upgrading the camel-spring-boot opentelemetry example from camel-opentelemetry to camel-opentelemetry2.

Test plan

• 91 camel-telemetry tests pass (84 existing + 7 new for the messaging extractor)
• Verified with the opentelemetry Spring Boot example: async Kafka traces now show 20 spans across all 4 services in a single trace (was broken into 7 separate traces before the fix)

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-telemetry

All tested modules (11 modules)

• Camel :: Common Telemetry
• Camel :: JBang :: MCP
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: Validate
• Camel :: Launcher :: Container
• Camel :: Micrometer :: Observability 2
• Camel :: Observability Services
• Camel :: Opentelemetry 2
• Camel :: Telemetry :: Dev
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator Maven Plugin

---

⚙️ View full build and test results

[squakez]

I think that the decode of the "dash" is something exclusive of JMS protocol, I am not aware of other protocols, for example Kafka, having the same limitation. I you notice, the encoding part belongs to CamelJMSHeadersSpanContextPropagationInjector class, so, I guess that if anything has to be done with this class, it makes sense to have the specular encoding part. Same for testing. It makes sense to have an encode/decode test using for consistency reason

[squakez]

I think you can instead change the AbstractMessaging and deal with the string/byte conversion there leaving the "dashing" problem to the specific JMS subclass and separating clearly the concerns.