Rewrite GOVERNANCE.md: subprojects, maintainer committees, steering charter

[gbartolini]

Draft the updated GOVERNANCE.md reflecting the federated subproject model.

Acceptance criteria

• Define the four subprojects and their repo scope, for example:
  • Operator (core): cloudnative-pg, api, machinery
  • CNPG-I / Plugins: cnpg-i, cnpg-i-machinery, plugin-barman-cloud, cnpg-i-hello-world
  • Distribution & Packaging: charts, artifacts, postgres-containers, postgis-containers, pgbouncer-containers, postgres-extensions-containers
  • Community & Docs: docs, cloudnative-pg.github.io, cnpg-playground, grafana-dashboards
• Document that tooling repos (ciclops, chaos-testing, daggerverse, barman-cloud library, webtest, postgres-trunk-containers) stay under component-owner maintenance without steering representation, unless revisited
• Write the Steering Committee charter: 5–7 seats, max 2 per organisation, 2-year staggered terms, composition (one rep per subproject + 1–2 elected Community Representatives)
• Enumerate what the steering committee owns vs. what stays with subproject maintainer committees (see "Proposed Model" in the restructuring doc for the full split)
• Update the ⅔-majority governance-change vote (/vote-governance via gitvote) to route through steering, org-balanced (see Draft initial status of COMPONENT-OWNERS.md file #3)
• PR reviewed and merged in cloudnative-pg/governance

Context

This is the single largest deliverable in the restructuring: most other tickets in this epic depend on the definitions it establishes.

[gbartolini]

The README already lists all our repositories, so I'd rather keep the repository-to-subproject classification there than in GOVERNANCE.md (any change there would otherwise require a Steering Committee vote). GOVERNANCE.md should only define the subprojects themselves.

Here's what I'm currently leaning towards:

• Core Projects: just the operator itself, for now.
• Supply Chain, grouping: Container Images, Libraries & Automation, Testing & Automation, plus a new "Distribution" category covering the three main ways we ship the software (artifacts for YAML manifests, charts for Helm charts, community-operators for OLM bundles).
• Community, Docs & Ecosystem, renamed from the original proposal's "Community, Docs & Monitoring." Grafana dashboards are all we have today, but the intent is closer work with other projects, especially in the CNCF space, not just observability.
• Extensibility, grouping: Interface & Plugins (CNPG-I), and PostgreSQL Extensions & Tooling (renamed from "Modules & Extensions" - see below).

A few notes on the reasoning:

• Supply Chain is also meant to cover the work we're doing with OpenSSF in preparation for the EU Cyber Resilience Act. That work is the foundation for a future conformance-program application for CNPG — possibly as its own subproject at that point.

• Extensibility: CNPG-I and Postgres extensions/modules are the two ways we extend the stack's two main components: CloudNativePG and PostgreSQL, respectively. I'd like to keep the door open for Postgres tooling that works beyond Kubernetes and isn't limited to compiled extensions (application libraries, or even backup and recovery tooling), which is why that category is "PostgreSQL Extensions & Tooling" rather than just "Modules & Extensions."