fix(topology): support unique helm values per worker cluster

[ani1609]

Description

Implements per-worker helm values feature allowing individual worker clusters to have custom helm chart configurations while maintaining full backward compatibility.

Overview

This enhancement enables users to specify custom helm chart values for individual worker clusters, providing greater flexibility in configuring worker-specific settings while preserving the existing global configuration approach.

Key Changes

Core Implementation

• Added HelmValues field to Cluster struct (pkg/internal/bootstrap-configuration.go)
• Implemented value merging logic in CreateWorkerSpecificHelmChart() (pkg/internal/worker.go)
• Updated worker installation to use merged per-worker values

Value Merging Behavior

1. Global values serve as defaults for all workers
2. Per-worker values override/extend global values
3. Workers without helm_values use global values only (backward compatible)

Example Usage

# Global defaults
helm_chart_configuration:
  worker_chart:
    values:
      resources.limits.cpu: "500m"
      resources.limits.memory: "512Mi"

# Per-worker overrides
workers:
  - name: high-perf-worker
    helm_values:
      resources.limits.cpu: "2000m"    # Override
      resources.limits.memory: "4Gi"   # Override
      nodeSelector.performance: "high" # New value

Fixes #68

How Has This Been Tested?

Test cases:

• Backward compatibility: Workers without helm_values use global configuration
• Value merging: Per-worker values correctly override global values
• New values: Per-worker specific values are properly added
• Edge cases: Empty helm_values fields are handled gracefully
• Integration: End-to-end worker deployment with custom values

Test configuration:

• Multiple worker clusters with varying helm value configurations
• Mixed scenarios with some workers having custom values and others using defaults
• Verification of actual deployed helm chart values in Kubernetes clusters

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR requires documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have tested it for all user roles.
• I have added all the required unit test cases.

Does this PR introduce a breaking change?

[ani1609]

hey @narmidm, mind taking a quick look at this when you get a chance?