Interoperability with Honeycomb beelines?

I'm interested in this being interoperable with Honeycomb (Beeline) integrations for other languages, and wanted to check if this was of interest:

Historically Honeycomb used an X-Honeycomb-Trace header, encoding trace ID, span ID, and some attached context. Recent updates have made it possible to also read traces using the W3C Trace Context headers. The outgoing headers still default to using the Honeycomb header, but there are plans to make this configurable.

In line with the above, the new default generated trace ID is a 128-bit identifier, and the span ID is a 64-bit identifier. These are encoded in a hexadecimal representation on the wire (so can be represented by text). This change is so that trace/span IDs can be compatible with both tracing systems.

eg: https://github.com/honeycombio/beeline-go/pull/113 and https://github.com/honeycombio/beeline-go/pull/110

Possible improvements:

1. Change trace and span IDs to String type, and generate IDs compatible with W3C
2. Support X-Honeycomb-Trace header format
3. Support W3C trace header format (actually I'm hoping to use this format, as it makes it much easier to interoperate with other services that don't directly support Honeycomb)
4. Some Beeline implementations also now support AWS X-Ray headers inbound, but I don't really care about it 😄
5. It would be nice to be able to configure which serialization is used for inbound or outbound requests, but not clear if that should be in this library, or in http4s integration.

The issue does not name files or tests; begin by reviewing the tracing ID representation and HTTP integration boundaries, especially the distinction between the library and http4s integration. Use the referenced Honeycomb Beeline changes to compare W3C and X-Honeycomb-Trace requirements, then define one supported serialization and a clear inbound/outbound configuration scope before implementation.