Support separate database instances per product

Summary

Currently, all products (Connect, Workbench, Package Manager) must share a single PostgreSQL server. The operator creates separate databases and users per product within that server, but there is no way to point individual products at different database instances.

Use Case

Customers may need per-product database instances for:

• Sizing — Connect may have heavier database workload than Workbench
• Availability — Different RDS/Azure DB tiers or failover configurations per product
• Compliance — Isolation requirements that go beyond logical database separation
• BYO database — Customer wants to reuse an existing database server for one product but use a managed one for others

Current Behavior

• A single main-database-url is resolved via DetermineMainDatabaseUrl() in internal/get_db_secret.go
• All product controllers use this same URL to create their databases
• Product CRDs have a PostgresDatabaseConfig with a Host field, but reconciliation still flows through the single main database URL

Proposed Behavior

Allow each product to optionally specify its own database connection, overriding the site-level default. For example:

spec:
  connect:
    databaseSettings:
      connectionSecret: "connect-db-secret"  # optional override
  workbench:
    databaseSettings:
      connectionSecret: "workbench-db-secret"  # optional override

Products without an override would continue using the site-level mainDatabaseCredentialSecret.

Start by reading internal/get_db_secret.go and tracing DetermineMainDatabaseUrl through the product controllers and their PostgresDatabaseConfig handling. Compare how the site-level mainDatabaseCredentialSecret currently reaches each product, then define the override and fallback paths described in the issue. Done means each product can use its own connection secret while products without one retain the site-level default.