feat(boto3): Add SQS/SNS trace propagation - #8145

### Description

Adds `Boto3Integration(propagate_traces=True)`. Setting it to `False`
stops the integration from changing the request params of AWS calls:

- Lambda `Invoke` no longer gets trace data in `ClientContext`.
- Once #8145 lands: SQS `SendMessage` / `SendMessageBatch` and SNS
`Publish` / `PublishBatch` no longer get `sentry-trace` / `baggage`
message attributes, and SQS `ReceiveMessage` no longer appends our names
to `MessageAttributeNames`.

The option gates the shared `get_request_params` hook, so it covers
every extension that uses it without per-service changes. Spans are
still created as before.

This is an escape hatch for setups where the added data breaks calls,
e.g. a queue or topic whose `MaximumMessageSize` is set below the 256
KiB the #8145 size check assumes, or consumers that reject unknown
attributes. The name matches `CeleryIntegration(propagate_traces=...)`.

HTTP `sentry-trace` / `baggage` headers on AWS requests are not
affected. They're also added by the stdlib integration and are already
controlled by `trace_propagation_targets`.

Independent of #8145. The SQS/SNS test cases pass trivially until #8145
is merged, and guard the option after that. Whichever PR merges second
needs a small conflict fix at the end of `test_trace_propagation.py`,
since both append tests there.

<!-- junior-request-attribution:start -->
via @sentrivana.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC0BTREZTS2Z%3A1794401901.814229 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC0BTREZTS2Z%3A1794401901.814229)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC0BTREZTS2Z%3A1794401901.814229/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Ivana Kellyer <131587164+sentrivana@users.noreply.github.com>
Co-authored-by: Ivana Kellyer <ivana.kellyer@sentry.io>

Matches the boto3 receive links from #8145.

)

### Description

Since #8137, #8142, and #8145, boto3 puts `sentry-trace` in SQS and SNS
message attributes, but nothing reads it on the Lambda side. This PR is
the smallest change that closes the loop for SQS- and SNS-triggered
functions. The Lambda integration now reads `sentry-trace` from each
record and adds a `message_origin` link from the invocation span to each
distinct producer span. This matches what the boto3 `ReceiveMessage`
span already does. Messages never become the invocation's parent.

It reads:
- SQS records: `messageAttributes["sentry-trace"].stringValue`
- SNS records: `Sns.MessageAttributes["sentry-trace"].Value`
- SNS → SQS without raw message delivery: the SNS envelope in the SQS
`body`, the same as boto3 does

Links are deduplicated, because a batch send gives many messages the
same producer span, and capped at 128, OTel's default, because Lambda
can deliver up to 10,000 SQS messages at once.

**Scope.** This is intentionally kept separate from the stretch stack.
It doesn't add `faas.trigger` (#8222) or `queue.process` spans (#8223),
and it doesn't touch `messaging.batch.message_count` (#8229). The
invocation span is otherwise unchanged. Synchronous `Invoke` propagation
through `ClientContext` is #8221. That PR changes the `continue_trace`
call and this one only adds `links=`, so the two are independent.

The link-building code repeats boto3's `_message_link` in a Lambda-event
shape: Lambda records use `messageAttributes` / `stringValue` / `body`,
while the boto3 response uses `MessageAttributes` / `StringValue` /
`Body`. Importing from the boto3 integration would make `aws_lambda`
depend on botocore.

**Testing.** `test_producer_links` sends SQS, SNS, and SNS-to-SQS events
to `BasicOkSpanStreaming`. It asserts the segment span's `links` and
that the segment span has no parent. It passes in CI's Cloud (Lambda)
jobs, and `ruff` and `mypy sentry_sdk` pass. `codecov/patch` is red
because the Lambda tests run in `sam local` containers, so their
coverage isn't counted.

#### Issues
* Part of #8081

<!-- junior-request-attribution:start -->
via **webb**, @sentrivana.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC09M26BC6A1%3A1794211222.463239 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC09M26BC6A1%3A1794211222.463239)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC09M26BC6A1%3A1794211222.463239/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Alexander Webb <alexander.webb@sentry.io>
Co-authored-by: Ivana Kellyer <131587164+sentrivana@users.noreply.github.com>