Support for legacy Cloud Trace propagation header

Describe your environment

We are using this module as part of ingress-nginx under Global application load balancer on Google Cloud Platform.
What was heavy used feature by us was connection of logged request by LB had connected tracing information.
As GCLB supports right now only legacy trace propagation mechanism and there is no immediate view on updates to WC3 standards we would like to add support for understanding X-Cloud-Trace-Context for nginx tracing at least on input.

As otel module for nginx does not understood that trace exist on request it create new one and propagated using WC3 headers. Our application are implemented with guidlines to prefere WC3 over legacy traces and this "disconnects" traces from LB from other system trace.

Versios:
Ingress-Nginx helm chart version: 4.10.0
Ingress-Nginx: v1.10.0
Nginx: 1.25.3
k8s: v1.29.1-gke.1589020
opentelemetry-contrib-cpp: aaa51e2297bcb34297f3c7aa44fa790497d2f7f3

Steps to reproduce
Deploy nginx under Classic Global Load balancer. Traces would differ between request and upstream of it. As consequence logs would also does not appear under same trace.

What is the expected behavior?
Have ability to switch input to understood legacy Cloud Trace Format

What is the actual behavior?
Legacy Cloud Trace propagation header is ignored

Additional context
I put report about Import/Export implementation to main library to not duplicate code as probably there are still services that are understood/produce only legacy traces https://github.com/open-telemetry/opentelemetry-cpp/issues/2683

Start by locating the nginx tracing module's propagation input handling and review the Import/Export implementation referenced in issue #2683. Reproduce the stated ingress-nginx and Google Cloud load-balancer behavior; done when X-Cloud-Trace-Context can be accepted on input and request and upstream traces remain connected.