feat: expose showAdditionalCommandArgs and listAdditionalCommandArgs

[davidalmgren95]

Summary

An ObjectStore already lets users tack extra command-line flags onto four of the six barman-cloud-* invocations the plugin shells out to:

barman command	existing field
barman-cloud-backup	data.additionalCommandArgs
barman-cloud-wal-archive	wal.archiveAdditionalCommandArgs
barman-cloud-wal-restore	wal.restoreAdditionalCommandArgs
barman-cloud-restore	data.restoreAdditionalCommandArgs (#914)

The remaining two — barman-cloud-backup-show (post-write verification) and barman-cloud-backup-list (retention pruning) — had no equivalent, which is the gap reported in #712.

This is observable in practice on S3-compatible endpoints that strictly require virtual-hosted-style addressing for LIST. On such backends:

• barman-cloud-backup accepts user-provided --addressing-style=virtual via the existing data.additionalCommandArgs ✅ — base backup completes and lands in the bucket
• barman-cloud-backup-show runs immediately afterwards with no way to thread the flag through, sends path-style by default, gets PathStyleRequestNotAllowed, exits with status 4
• The plugin marks the otherwise-successful backup as phase: failed
• Retention pruning (which goes via barman-cloud-backup-list) is similarly broken — old backups silently never get expired

So user-visible Backup CR status is wrong and retention is silently disabled, even though the actual base-backup data is intact in the bucket. The Backup CRs from such clusters look like:

```
NAME AGE METHOD PHASE ERROR
my-cluster-db-backup-20260524000000 2d11h plugin failed rpc error: code = Unknown desc = exit status 4
my-cluster-db-backup-20260525000000 35h plugin failed rpc error: code = Unknown desc = exit status 4
```

with plugin logs showing:

```
{level:info, msg:"Starting barman-cloud-backup", options:[..., "--addressing-style=virtual", ...]}
{level:info, msg:"Completed barman-cloud-backup", ...}
{level:error, logger:"barman", msg:"Can't extract backup id", command:"barman-cloud-backup-show",
options:["--format","json","--endpoint-url",...,"--cloud-provider","aws-s3","s3://bucket/path/","server-name","backup-..."],
stderr:"ERROR: Barman cloud backup show exception: An error occurred (PathStyleRequestNotAllowed)\n"}
```

Note the --addressing-style=virtual is present on the first invocation but missing on the second.

Changes

• New CRD fields under spec.configuration.data:
  • showAdditionalCommandArgs (passed to barman-cloud-backup-show)
  • listAdditionalCommandArgs (passed to barman-cloud-backup-list)
• CRD YAML in config/crd/bases/barmancloud.cnpg.io_objectstores.yaml and manifest.yaml updated to include the two new array fields
• web/docs/misc.md updated to list all four args fields, with a note on the cross-cutting --addressing-style=virtual use case

No Go code changes are needed in this repo — the actual plumbing lives in the sister PR against cloudnative-pg/barman-cloud#249, which adds the matching Go fields, Append* helpers, and the call-site changes inside GetBackupByName and GetBackupList. Once that PR merges and a barman-cloud release is cut, bumping go.mod here will pick up the new behavior automatically.

Sister PR (must merge first)

cloudnative-pg/barman-cloud#249

Closes #712