fix: honour the object store requested by a Backup resource

[ildar-fix]

Closes #611

Problem

The operator relays the parameters of a Backup resource to the plugin in the BackupRequest
(pkg/management/postgres/webserver/plugin_backup.go -> internal/cnpi/plugin/client/backup.go), but
BackupServiceImplementation.Backup builds its configuration from the Cluster alone and never reads
request.Parameters. A Backup asking for a different object store is written to the cluster one, and it ends
up completed with no warning: the only symptom is an archive that stays empty.

What this does

First commit applies the parameters of the Backup on top of the configuration derived from the Cluster, so
that barmanObjectName and serverName select the destination of that single backup. A Backup without
parameters behaves exactly as before.

Second commit adds the additionalBarmanObjectNames cluster level parameter. It is needed to make the first one
usable: the Role bound to the instance service account is built from the object stores the Cluster refers to,
so a Backup naming any other store fails with objectstores.barmancloud.cnpg.io "..." is forbidden. The
parameter is a comma separated list of stores that take part in the RBAC and in the certificates of the
instances, while nothing is routed to them.

# Cluster
plugins:
  - name: barman-cloud.cloudnative-pg.io
    isWALArchiver: true
    parameters:
      barmanObjectName: minio-store
      additionalBarmanObjectNames: archive-store
---
# Backup
spec:
  method: plugin
  cluster:
    name: cluster-example
  pluginConfiguration:
    name: barman-cloud.cloudnative-pg.io
    parameters:
      barmanObjectName: archive-store

The two commits are separate on purpose: if you would rather widen the Role some other way, the first one stands
on its own.

Testing

Unit tests are added to the existing Ginkgo suite in internal/cnpgi/operator/config.

Verified on a stand with CNPG 1.30.0 and an S3 backend: a Backup requesting archive-store lands in that
store while WALs keep going to the cluster store, the cluster store is left untouched, and a cluster
bootstrapped from that pair comes up with all the data. Without the second commit the same Backup fails with
the forbidden error above.