Feature: Support selective per-CRD installation via values.yaml

## Current behaviour
The chart installs all 10 CRDs as a single all-or-nothing block:

```yaml
# values.yaml
crds:
create: true # all or nothing, no per-CRD control
```

The entire `templates/crds/crds.yaml` (18k lines, 10 CRDs) is wrapped in a single `{{- if .Values.crds.create }}` gate.

## Expected behaviour
Allow per-CRD toggles so operators can install only what they use:

```yaml
crds:
clusters: true
backups: false
scheduledbackups: false
poolers: false
databases: false
publications: false
subscriptions: false
imagecatalogs: false
clusterimagecatalogs: false
failoverquorums: false
```

## Why this matters
In multi-tenant clusters where a platform team governs cluster-scoped resources, clients must justify every CRD registered with the API server. In practice, most deployments only use `clusters` (and optionally `backups` / `scheduledbackups`). The remaining 7 CRDs are installed but never instantiated, which creates an unnecessary audit surface in regulated environments.

## Workaround today
Set `crds.create: false` and manage CRDs manually outside the chart — but this breaks automated CRD upgrades on chart updates.

Start with values.yaml and templates/crds/crds.yaml, tracing the existing crds.create gate and the ten CRDs listed in the issue. Verify the chart's rendered output for different per-CRD settings; done means each toggle controls only its named CRD while automated CRD upgrades still work.

Written by the indexing model from the issue text.