Nginx instrumentation: Base span start/end on `request_time`

Is your feature request related to a problem?
Yes: Span duration may not be as accurate as it could be. This is based on span starting/ending in such a way that start and end times are implicitly the "current" time. E.g., here's how the span is ended:
https://github.com/open-telemetry/opentelemetry-cpp-contrib/blob/32bcaf70a1f5d07187233c60e5dfc51abf887e42/instrumentation/nginx/src/otel_ngx_module.cpp#L277

The potentials for inaccuracy are:

• the span isn't started exactly when the first request byte is received from the client
• the span isn't ended exactly when the last response byte is sent to the client

Describe the solution you'd like
There might be a more accurate span duration to try and use: the request_time embedded variable:

request processing time in seconds with a milliseconds resolution (1.3.9, 1.2.6); time elapsed since the first bytes were read from the client

I'm not sure if that's a meaningfully different definition than the same-named variable available during request logging:

request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client

What I'm least sure about is what the span start or end times ought be chosen as such that their difference is request_time.

Describe alternatives you've considered
Just leave it as-is. I haven't quantified the size of inaccuracy that I'm alleging; it may be extremely negligible.

Start by reading instrumentation/nginx/src/otel_ngx_module.cpp around line 277 and the linked Nginx documentation for request_time. Compare the variable's timing semantics with the current span lifecycle and determine what start and end timestamps would satisfy them. Done means the timing behavior and its accuracy tradeoffs are defined well enough to implement and validate.