Add an options to flow the incoming distributed tracing headers

Currently YARP would remove the distributed tracing headers from an incoming requests, and the new updated headers is being added to it by `SocketsHttpHandler`. These new headers counts YARP as a SPAN, and if we look at the distributed tracing in a tool like Zipkin, the hierarchy would be [client -> YARP -> Destination]. Although This would happen only when all three applications are logging to a distributed tracing system.

There might be some scenarios when YARP is not configured to be in part of distributed tracing system or users don't want to count YARP as a SPAN in distributed tracing system. In this case I think the hierarchy between client and destination would be lost because of the missing link (YARP). In this case an option for clusters to just flow the incoming distributed tracing headers is helpful.

The issue names cluster configuration and SocketsHttpHandler as the relevant areas, but no files or tests. Start by tracing how incoming distributed tracing headers are removed or replaced for outgoing requests, then review how cluster options are defined. Done means a cluster-level option can preserve incoming headers and the client-to-destination trace hierarchy remains intact.

Written by the indexing model from the issue text.