Revisit header name -- Server-Timing vs. traceresponse

Related to #69, I would like to reopen the discussion around the header name for the client propagation of server tracing information.

The current state of the art among practitioners is to use the Server-Timing header, which is part of a safe-list of browsers today. A new header, such as traceresponse, would require a lot of effort to get included in those lists and take a long time before this is ubiquitous among client devices.

The linked issue was closed stating that it was decided against using Server-Timing, but without giving a reason for that. As I mentioned on that issue, by looking at the minutes, I could guess that the reason is related to this comment:

Yoav: This should be opt in, with the bare minimum number of resources that you need.

If that's the concern, isn't the server side already opting in by adding the response metric to this header? Like:

Server-Timing: traceresponse;desc=00-{trace-id}-{child-id}-01

If there's no other reason, I would like to propose a change to the current draft, so that the traceresponse isn't a header, but a metric of the Server-Timing header. This way, we can co-exist with other competing standards and offer a lower-friction migration path to people using Server-Timing today.

References:

• https://docs.splunk.com/observability/en/gdi/get-data-in/rum/browser/manual-rum-browser-instrumentation.html#add-server-trace-context-from-splunk-apm
• https://github.com/open-telemetry/opentelemetry-php-contrib/pull/213
• https://www.ibm.com/docs/en/instana-observability/current?topic=websites-backend-correlation#ensure-that-the-backend-is-traced

Start by reading the linked issue #69, the current trace-context draft, and the referenced Server-Timing materials to understand the prior decision. Compare the proposed traceresponse metric format with the existing draft and document whether the header change is technically and interoperably justified; done means a resolved specification decision.