OTL-3190 Additional fixes for operator install order issues using Helm hooks

[jvoravong]

Description
Helm install failures occur in rare cases due to deployment order issues:

• Instrumentation Object: May fail because the Operator and its webhook are not ready.
• Cert-Manager Certificate: May fail because Cert-Manager is not yet initialized.

Proposed Solution
Add Helm hooks to enforce readiness checks and ensure resources are deployed in the correct order. Cert-Manager and Operator readiness will be validated before Instrumentation deployment. We will use appropriate Hook weight values to ensure each related operation is completed sequentially.

Installation Order

1. Default Installation Phase: Deploy Cert-Manager, Operator, and Operator CRDs.
2. Cert-Manager Readiness Check: Post-install hook (weight 1) verifies Cert-Manager is operational.
3. Install Issuer: Post-install hook (weight 2) deploys the Cert-Manager Issuer.
4. Install Certificate: Post-install hook (weight 3) deploys the Cert-Manager Certificate.
5. Operator Readiness Checks: Post-install hooks (weight 4) validate the Operator and related webhook are ready.
6. Install Instrumentation: Post-install hook (weight 5) deploys Instrumentation resources.

Benefits

• Ensures dependencies are deployed in the correct order.
• Mitigates Helm installation errors reported from the field.

Cons

• Using Helm hooks like this and this much is an anti-pattern for Helm.

Callouts

• Future Refactoring: We may refactor Cert-Manager usage and CRD installation in the near future, potentially eliminating the need for post-install hooks. While this PR provides an effective interim solution, it may be short-lived within this project.

Testing

• Verified with local and lab Kubernetes clusters.

Related Alernative solution: #1561

[jvoravong]

This ticket can be closed in favor of #1586