Allow using the S3 blob store with services that don't support conditional writes

Correction of the earlier diagnosis, measured on OVHcloud Object Storage (eu-west-par) on 2026-10-12:

• PutObject and CompleteMultipartUpload with If-None-Match: * are enforced (412 when the object exists; with 8 concurrent PUTs of the same new key, exactly one succeeded, in three runs).
• UploadPartCopy evaluates x-amz-copy-source-if-match (200 with the right ETag, 412 with a wrong one). UploadPartCopy is therefore not affected, contrary to the previous comment.
• Only CopyObject rejects conditions: x-amz-copy-source-if-match, x-amz-copy-source-if-none-match and If-None-Match all get 501 Not Implemented.

Following the review, the change is being amended to work with S3-compatible services that don't support some conditional requests, with two properties, both true by default:

• store.s3.conditionalWrites: the conditions of uploads and multipart copies (If-None-Match on PutObject and CompleteMultipartUpload, x-amz-copy-source-if-match on UploadPartCopy).
• store.s3.conditionalCopies: the condition of the single-request copy (If-None-Match on CopyObject).
  The source precondition is no longer sent on CopyObject at all (a single CopyObject reads the source once). OVHcloud Object Storage needs store.s3.conditionalCopies=false only.

Follow-ups: XCOMMONS-3825 (detect automatically which conditional requests the service supports), XCOMMONS-3826 (non-atomic CREATE_NEW moves in the filesystem blob store).