Add an S3 transport built on the AWS SDK for Java 2.x - #2290

Step 1 of #2289 (#2291 is the longer-term direction): a new maven-resolver-transport-s3 module on the AWS SDK for Java 2.x, next to the MinIO one, which is not touched. Once this has shipped, #2289 continues with deprecating and then dropping maven-resolver-transport-minio.

The module is the MinIO transporter ported call for call (headObject, getObject, putObject, close), with the same object name mappers under org.eclipse.aether.transport.s3, the same s3+http(s) opt-in form and the same plaintext refusal. Three things differ because the SDK makes them possible or necessary:

• Credentials: repository authentication (username as access key, password as secret key) is used when set; without it the SDK default provider chain applies, so environment variables, profiles, container and instance roles work as they do with any AWS tool. The MinIO transporter refuses to start without repository authentication.
• Region: a new aether.transport.s3.region key; unset, the SDK default region chain is consulted and us-east-1 is the fallback, which S3-compatible stores accept.
• Client settings: path-style access, and requestChecksumCalculation and responseChecksumValidation set to WHEN_REQUIRED, since SDK 2.30.0 otherwise sends CRC32 trailers that MinIO-compatible stores reject (S3 default integrity protection change - version `2.30.0` aws/aws-sdk-java-v2#5802).

Only s3 and url-connection-client are depended on; the SDK's Apache, Apache 5 and Netty HTTP engines are excluded. Runtime closure measured on a scratch POM: 8.9 MB in 32 jars, against 21.2 MB in 22 jars for the MinIO client (Bouncy Castle, Guava, snappy, Kotlin, Jackson, commons-compress). Both clients are Java 8 bytecode.

The factory also accepts the MinIO transport's minio+http(s) URL form and reads its aether.transport.minio.* keys as fallbacks for the three keys the two transports share, so a repository set up for the MinIO transport works here unchanged. Its default priority is 1.0, above the MinIO factory's 0.0, so with both modules present every s3+ and minio+ repository resolves to this transporter; without this module the MinIO one keeps working as before. The deployment page lists both rows, and maven-resolver-tools picks up the new configuration keys for the generated configuration page.

Verified: mvn -pl maven-resolver-transport-s3 -am -P run-its verify on JDK 21 with Docker → BUILD SUCCESS; the integration test runs the same peek, get and put cases as the MinIO one against the same container image, plus get-to-file and put-from-file.