Figure out the relationship with Quarkus AWS extensions

Reasons for depending on Quarkus AWS extensions:

* Re-use of their native configuration
* Better quality by relying on their tests and battle-testing by their community
* Simplified testing on our side: we currently test each AWS component with and without the associated Quarkus AWS extension

Concerns:

* We do not want to be forced to use their configuration; each client must be configurable programmatically; none of their config props should be required

No source files, tests, or entry points are named. Start by tracing how AWS components currently use Quarkus AWS extensions and their configuration, then document an agreed relationship that preserves programmatic client configuration and defines what testing can be shared.

Written by the indexing model from the issue text.