feat: data sink, replaced hard coded secret for credentials

[mirzakopic]

Introduce DataSink CRD for Configurable Telemetry Export

This PR introduces the new DataSink Custom Resource Definition (CRD) as the primary mechanism for configuring telemetry export endpoints, replacing the previous hardcoded secret-based configuration approach. The DataSink CRD enables declarative configuration of OTLP/HTTP endpoints with flexible authentication via Kubernetes Secrets, significantly improving the operator's configurability and maintainability.

Key Changes:

🚀 New Feature: DataSink CRD

• Added DataSink CRD (api/v1alpha1/datasink_types.go) for declarative OTLP/HTTP endpoint configuration
• Updated all metric controllers (Metric, ManagedMetric, FederatedMetric, FederatedManagedMetric) to consume DataSink resources instead of hardcoded secrets
• Implemented centralized DataSink retrieval logic in internal/controller/datasink_utils.go to reduce code duplication
• Enhanced namespace lookup logic supporting both local development (OPERATOR_CONFIG_NAMESPACE) and in-cluster deployment (POD_NAMESPACE) scenarios
• Fixed OTLP client initialization (internal/clientoptl/optl.go) to properly parse complete endpoint URLs from DataSink configurations, including correct handling of host, path, and scheme components
• Updated Makefile, RBAC configurations, and provided comprehensive examples in examples/datasink/ directory
• Added dedicated documentation for DataSink configuration and usage

🔧 Improvements: Enhanced Status Condition Handling

• Standardized status condition management across all four metric controllers with consistent Ready condition handling
• Introduced TypeReady constant and helper functions (ReadyTrue, ReadyFalse, ReadyUnknown) for reliable condition state management
• Implemented defer-based condition setting to ensure the Ready condition is properly initialized and updated (True, False, or Unknown with specific reasons) at the end of each reconciliation loop

Impact:
This change significantly improves the operator's flexibility by allowing users to define multiple telemetry endpoints declaratively through Kubernetes resources rather than relying on hardcoded configurations. The DataSink CRD provides a clean separation of concerns, better security through Secret-based authentication, and improved maintainability for complex telemetry routing scenarios.