Allow separate configuration for the replica connection pooler

[omkar619-dev]

Adds a replicaConnectionPooler section to the Postgres manifest so the replica pooler can be configured independently of the master pooler.

The new type carries numberOfInstances, mode, dockerImage, maxDBConnections and resources. It deliberately does not carry user or schema: those are cluster-scoped rather than per-pooler. The two places that read them — poolerUser, and the lookup-function install in syncConnectionPooler — create objects once per cluster that both poolers share, so leaving those two fields out means neither site has to become role-aware.

Fields are pointer-typed so unset means "inherit from connectionPooler" rather than "zero". A manifest using enableReplicaConnectionPooler: true with only a connectionPooler section behaves exactly as it does today.

How it works

effectiveConnectionPoolerSpec(spec, role) resolves the settings for a role: master returns connectionPooler unchanged, replica returns connectionPooler with any field explicitly set in replicaConnectionPooler laid over it. It returns the existing ConnectionPooler type, so needSyncConnectionPoolerSpecs and needSyncConnectionPoolerDefaults keep their signatures, and it never returns nil, which replaces a nil check that four call sites each repeated.

Those four are getConnectionPoolerEnvVars (the only signature change — it gains the role, and has a single caller), generateConnectionPoolerPodTemplate (already took the role and ignored it), generateConnectionPoolerDeployment
(has it via connectionPooler.Role), and the spec comparison in syncConnectionPoolerWorker.

That last one though is the subtle one. If the comparison keeps looking only at spec.ConnectionPooler, editing replicaConnectionPooler on a live cluster produces no diff, the deployment is never regenerated, and the replica pooler
silently keeps its old settings — correct on create, inert on update. TestReplicaConnectionPoolerSyncOnOverrideChange drives syncConnectionPooler against the fake client and asserts the replica deployment moves from 2 to 4
instances while the master stays at 2. I confirmed it fails (expected 4, actual 2) with the role argument removed.

Also included

• TestEffectiveConnectionPoolerSpec: six cases covering inherit, partial override, full override and the empty-section cases.
• Regenerated CRD schema (all three copies) and deepcopy.
• Docs: a replicaConnectionPooler section in the manifest reference, an example in the user guide, and a commented block in the complete manifest.

Left out deliberately

Setting connectionPooler on its own implicitly enables the master pooler, but there is no replica equivalent, so enableReplicaConnectionPooler remains required and a replicaConnectionPooler section alone won't switch anything on.
That felt outside the scope of this change, but happy to make the two symmetric if you'd prefer.

Closes #3113