UseWolverine change the url of SQS service

[SebastianGaud]

Describe the bug I created an abstraction over AWS SQS service, this way I can push the messages on a queue independetly from Wolverine because I use it in other part of the code and I use the AWS SDK for .NET.

So for example I have a service that push to a queue named -> XXXXXXX-XXXXX-XXXXX on localstack but when I inser "UseWolverine" on my builder.Host I can't reach anymore for that queue because the url become the default SQS url.

To Reproduce

1. Use the AWS SDK for .NET anywhere in your code and try to send a message to specific queue url (doesn't matter if localstack or not)
2. Add UseWolverine() on your builder.Host
3. You send message to that queue because the url is overwritten without the QueueName

Expected behavior Wolverine shouldn't change the default behaviour of other SDKs. Especially if I just use wolverine for its local queue feature and I don't reference the Wolverine package for SQS transport

Desktop (please complete the following information):

• 2.9.0

Additional context The server part is just an asp.net 8 application, with a React frontend.

[jeremydmiller]

@SebastianGaud You're doing something non-idiomatic here. I don't get what you're doing or how to test this or have any real idea about why you're seeing the behavior you are. Not 100% convinced that it's wolverine either. Sorry, but I think this one is "I take pull requests" if you want to do some spelunking into the Wolverine usage of the SQS SDK to figure out why your Url gets changed -- but the good news is that I will actually take the PR:)

[SebastianGaud]

Upon closer examination of the code, it appears that utilizing the NuGet package WolverineFx (version 2.7.0) and adding Wolverine with the extension method UseWolverine on the builder.Host results in an unintended behavior. Specifically, an instance of AmazonSQSConfig is added into the dependency injection (DI) container, and this instance overrides my own injection of the same model.

In my opinion, WolverineFx should not automatically inject such models without explicitly referencing the WolverineFx.Sqs package. This behavior can lead to unexpected configuration conflicts.