Exponential Backoff Support for SQS Message Retry Through Per-message Visibilty Timeouts.

### Describe the feature

Add support for configurable per-failure visibility timeout control in the SQS message poller, enabling exponential backoff between processing retry attempts without requiring any application-level changes to message handlers.

### Use Case

When processing messages, if an error occurs, it often doesn't make sense to retry the message immediately.

The visibility timeout of a message is usually set to the length of time + some buffer on how long it will take to process the message. So, if it's 30 seconds to process, then visibilty timeout will be 45 seconds. If we think of an error case though, where the error is caused by a downstream slow down, for example, a database having an issue, we may cycle through the number of retries allowed before going to the DLQ within a few minutes.

I would like it to be more programmatic on when the retry occurs based on information from the message. With this, I could set the retry for 1 minute from the first failure, but 3 hours after the 4th failure.

### Proposed Solution

Two different options. Both options require surfacing `ApproximateReceiveCount` in `SQSMetadata` by populating it during deserialization in `MessageMetadataHandler.CreateSQSMetadata()`.

**Option 1 — Poller-level configuration**

Add a `Func? VisibilityTimeoutOnFailure` delegate to `SQSMessagePollerOptions`. The framework calls `ChangeMessageVisibility` automatically in `ReportMessageFailureAsync` when a handler fails, using the returned delay. No handler changes required.

**Option 2 — Handler-level return value**

Extend `MessageProcessStatus` to allow returning a visibility timeout alongside a failure result, e.g. `MessageProcessStatus.Failed(TimeSpan delay)`. The framework applies the delay when it processes the failed status. This gives per-message control at the cost of updating each handler.

### Other Information

_No response_

### Acknowledgements

- [x] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### AWS.Messaging (or related) package versions

AWS.Messaging

### Targeted .NET Platform

.NET 8 +

### Operating System and version

Linux Containers

Start by reading MessageMetadataHandler.CreateSQSMetadata() and tracing failure handling through ReportMessageFailureAsync. Compare the proposed SQSMessagePollerOptions and MessageProcessStatus approaches, including where ChangeMessageVisibility would be applied. Done means exposing ApproximateReceiveCount and implementing a decided retry-timeout design without requiring handler changes if that option is selected.

Written by the indexing model from the issue text.