Allow distributed tracing for non-API Gateway trigger type

**Is your feature request related to a problem? Please describe.**
Recently, behaviour was added to support span links whenever the traceparent was present in the SQS message attribute.
This feature is nice, however in my use case, I have multiple microservices communicating between each other via SQS.

The AWS API Gateway trigger type can receive the traceparent and tracestate via HTTP headers injected by the Agent on the upstream service. This allows services communicating via HTTP calls to maintain a clear linear execution between microservices while also keeping all logs in one place.

My use case is that I do something similar, but the inter-microservice communication is done via SQS, as it provides a cheaper alternative to API Gateway for internal communication, while keeping it unexposed to the internet.

**Describe the solution you'd like**
I believe an option that allows the `traceparent` and `tracestate` MessageAttributes to be used when the agent starts the transaction via the Lambda instrumentation would be useful.

The benefits would include having the entire chained execution in one APM trace, so that I can view all logs in one place and not have to navigate through linked spans, as well as proper Service Maps built for multiple microservices that are part of the same execution.

**Describe alternatives you've considered**
Previously the workaround for this was to have a function before the lambda instrumentation that adds the traceparent from MessageAttributes into a `headers` object.
This behaviour is no longer possible since changes to the agent have decoupled transaction set-up specific logic from the different trigger types. Attempting to fake an API gateway trigger will result in bad transaction information.