feat(io/s3): support connect timeout property

[Revanth14]

Fixes #941

Summary

• Support the s3.connect-timeout property for S3 clients.
• Accept PyIceberg-compatible numeric seconds such as 60 and 60.0, plus Go duration strings such as 5s.
• Apply the value to the AWS SDK buildable client's dialer timeout.
• Compose connect timeout with s3.proxy-uri by sharing the same buildable HTTP client.
• Reject zero and negative timeout values with a clear error.

Supersedes #950 and addresses all three items from laskoviymishka's review: float-seconds parsing, zero/negative rejection, and proxy+timeout composition test.

Testing

• go test ./io/gocloud/...

Release note

S3 now supports the s3.connect-timeout property, accepting numeric seconds like 60/60.0 and Go duration strings like 5s.

[Revanth14]

@laskoviymishka @tanmayrauth
This should address the feedback from #950. Could you please review when you have some time?

[tanmayrauth]

Not a blocker for this PR since the same pattern already exists for s3.proxy-uri, but worth flagging: createS3Bucket (lines 167-176) applies tuned transport options (MaxIdleConnsPerHost: 256, MaxIdleConns: 256, etc.) only when awscfg.HTTPClient == nil. Setting s3.connect-timeout now populates HTTPClient here, so callers fall back to the AWS SDK's awshttp.NewBuildableClient() defaults — notably MaxIdleConnsPerHost: 10 instead of 256, which can hurt highly parallel scans. Could you open a follow-up issue to apply the same transport tuning inside ParseAWSConfig (or factor a shared newBuildableClient() helper) so the proxy and connect-timeout paths don't silently regress connection pooling?