investigate trace-context propagation after `transaction_max_spans` is hit

Before [this PR](https://github.com/elastic/apm-agent-nodejs/pull/2694) that was part of adding `transaction.dropped_spans_stats` support, the creation of a span that overshot `transactionMaxSpans` would return null. After that change, a `Span` instance is returned (though it has `.isRecorded()` false -- where "recorded" here corresponds to the `sampled` flag on that span's traceparent being false).

Looking at trace-context propagation for outgoing HTTP requests:
https://github.com/elastic/apm-agent-nodejs/blob/v3.42.0/lib/instrumentation/http-shared.js#L209-L225
there are two impacts of the above change:

1. We will be propagating a `traceparent` with the `sampled` flag set false.
2. We will be propagating a `traceparent` with the `parent-id` set to the ID of the *dropped* span.

The latter *would* cause a broken trace, but given the former, we wouldn't typically expect a downstream service to continue the trace anyway. Before the change (to no longer return `null` from `Transaction.prototype.createSpan()`) the APM agent would use the trace-context details from whatever parent span (or the transaction) that *was* recorded -- so we would get a continued trace.

The same issue will exist for SQS trace-context propagation after the coming change in #3044.