Propagation fails because trace ID value does not observe Cloud Logging format.

The [formatter](https://github.com/GoogleCloudPlatform/opentelemetry-operations-python/blob/cc61f23a5ff2f16f4aa2c38d07e55153828849cc/samples/instrumentation-quickstart/gcp_logging.py#L23) in this sample correctly renames the OpenTelemetry field names to their GCP counterparts, however this does not address the format difference in the trace ID _value_. Cloud Logging is expecting `projects/{project-id}/traces/{trace-id}`, but we are only providing the raw trace ID here.

We can propagate existing Cloud Logging trace ID's by including something like this:
```python
from opentelemetry.propagate import set_global_textmap
from opentelemetry.propagators.cloud_trace_propagator import CloudTraceFormatPropagator

LoggingInstrumentor().instrument()
set_global_textmap(CloudTraceFormatPropagator())
```
This _will_ attach the propagated trace ID to our logging calls correctly, however with the JsonFormatter in this sample alone the logs would not correlate properly in GCP Logs Explorer or Trace Explorer since the `projects/{project-id}/traces/` prefix is still missing from the trace ID value. We can use the `log_hook` argument on LoggingInstrumentor to modify the field value like this:
```python
def _log_hook(span: Span, record: logging.LogRecord) -> None:
if span and span.is_recording():
if hasattr(record, "otelTraceID"):
record.otelTraceID = (
f"projects/{PROJECT_ID}/traces/{record.otelTraceID}"
)
LoggingInstrumentor().instrument(log_hook=_log_hook)
```
(Let's pretend we queried `metadata.google.internal` or something and already set `PROJECT_ID` somewhere for the sake of this example.) With this, the `otelTraceID` _value_ will first be changed to the correct format by the `LoggingInstrumentor` hook, then the field is renamed to `logging.googleapis.com/trace` by the `JsonFormatter` in the sample, and now traces will correlate properly in Logs Explorer/Trace Explorer! Hope this helps.