Fix HTTP 403 errors in ROS3 VFD for object keys that need URI encoding

[ajelenak]

The ROS3 VFD appended the raw object key to the HTTP request path. Because the signing configuration disables use_double_uri_encode (the correct setting for S3), the SigV4 signer uses the request path verbatim, so keys containing characters that AWS requires to be percent-encoded -- such as '=' in Hive-style "key=value" partition prefixes, '+', or spaces -- produced signatures that disagree with S3's server-side recomputation. S3 rejects such requests with SignatureDoesNotMatch, surfaced as a bodyless HTTP 403 that is indistinguishable from a permissions error on a HEAD request, even though other S3 clients (AWS CLI, boto3, s3fs) could read the same objects.

Percent-encode the object key exactly once when building the request
path, using the AWS CRT's aws_byte_buf_append_encoding_uri_path(),
which implements the SigV4 path encoding ('/' is preserved). The
function comes from aws-c-common, which is already a transitive
dependency through aws-c-s3, so no new dependency is introduced.

Note that object keys must now be passed to the VFD unencoded; a key
that was pre-encoded as a workaround for this issue will now be
double-encoded and fail to resolve.

Also adds a regression test that opens an HDF5 file stored under a
Hive-style object key with signed requests, along with TEST_KEYS
support in runProxy.cmake so s3proxy fixture files can be uploaded
under object keys that differ from their file names.

[github-actions]

Review Checklist

This PR touches the following areas. Each needs at least one
sign-off from its listed owners before merging — an approval
covering only one area does not satisfy the others.

• src ✅ — @jhendersonHDF
• test ✅ — @jhendersonHDF
• *.cmake ✅ — @jhendersonHDF
• config ✅ — @jhendersonHDF
• release_docs ✅ — @lrknox

✅ All areas have been signed off.