feat: Add Helm installation method for Chaos Infrastructure

[akhilmukkara]

• Added HelmInstallationCommand component to display Helm installation commands
• Modified KubernetesChaosInfrastructureGreenfield to include tabs for Manifest and Helm installation methods
• Auto-populated Helm commands with infraID, accessKey, projectID, and other required values
• Added prerequisites and verification instructions for Helm installation

Fixes #4897

Proposed changes

This PR implements a new Helm installation method for deploying Chaos Infrastructure, as requested in #4897.

Users can now choose between Manifest (kubectl) or Helm installation methods when deploying Chaos Infrastructure through the ChaosCenter UI.

Changes Made

1. Created HelmInstallationCommand Component
   Location: src/components/HelmInstallationCommand/

• Generates Helm installation commands with pre-populated values
• Displays commands in a copyable code block
• Shows prerequisites and verification instructions

2. Modified Infrastructure Deployment UI
   Location: src/views/KubernetesChaosInfrastructureGreenfield/

• Added Tabs component with "Manifest" and "Helm" options
• Manifest tab preserves existing functionality
• Helm tab displays the new HelmInstallationCommand component

How It Works

When deploying Chaos Infrastructure, users now see two tabs:

Manifest Tab: Original kubectl apply method (unchanged)

Helm Tab: New Helm installation with auto-generated command:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

helm install  litmuschaos/litmus-agent \
  --namespace  \
  --set "INFRA_ID=" \
  --set "ACCESS_KEY=" \
  --set "LITMUS_URL=" \
  # ... all values pre-filled

All values are automatically populated from user inputs and environment context.

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• New feature (non-breaking change which adds functionality)
• Bugfix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices applies)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have signed the commit for DCO to be passed.
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Dependency

• Please add the links to the dependent PR need to be merged before this (if any).

Testing & Verification
✅ Successfully tested in live GKE environment:

Visual Rendering: Tabs display correctly in the infrastructure deployment screen
Tab Switching: Smooth transition between "Manifest" and "Helm" tabs
Helm Command Generation: All values (infraID, accessKey, projectID, etc.) are correctly auto-populated
Copy-to-Clipboard: Functionality works as expected
UI/UX Flow: Intuitive user experience maintained
No Breaking Changes: Existing Manifest tab functionality preserved completely

Testing Environment:

Deployed LitmusChaos via Helm on Google Kubernetes Engine (GKE)
Tested with Kubernetes v1.28+
Verified all MongoDB read/write operations working correctly
No console errors or backend issues detected

Implementation Details:

Used string concatenation for TypeScript compatibility
Followed existing component patterns (CodeBlock, Layout, Text from @harnessio/uicore)
Helm chart (litmuschaos/litmus-agent) is production-ready and maintained by the LitmusChaos team