Dynamically create the unified 'kata-cc' RuntimeClass based on detected hardware

User Story
As a developer, I want a TEE-specific RuntimeClass created automatically, so that I can deploy confidential workloads with the correct TEE settings.

  Description:

  Implement dynamic creation of the kata-cc RuntimeClass based on detected TEE hardware capabilities. The operator will create a single RuntimeClass and configure its handler (kata-cc-intel or kata-cc-amd) and nodeSelector fields with the appropriate values for the detected TEE. This ensures that confidential workloads are scheduled only to nodes with the correct hardware and use the correct runtime handler.

  Acceptance Criteria:

•   When a single TEE type (TDX or SNP) is detected on nodes in the pool, a RuntimeClass named kata-cc is created.
• The handler field of the kata-cc RuntimeClass is set to kata-cc-intel for TDX nodes or kata-cc-amd for SNP nodes.

• The nodeSelector of the RuntimeClass is correctly set to the NFD label of the detected TEE (e.g., amd.feature.node.kubernetes.io/snp: "true").

• (GAP) The scheduling section of the RuntimeClass should be updated to include the necessary TEE-specific resource requirements (e.g., tdx.intel.com/keys: 1).

• The operator correctly cleans up the kata-cc RuntimeClass when the confidential computing feature is disabled or TEE hardware is no longer detected.

  Testing Considerations:

  - Unit Tests: RuntimeClass generation with correct specifications for each TEE type

  - Unit Tests: Test node selector and resource requirement settings

  - Integration Tests: RuntimeClass creation/update/deletion based on hardware changes

  - Integration Tests: Verify only appropriate RuntimeClass is created per TEE type

  - Validation Tests: RuntimeClass YAML structure and field correctness

  - E2E Tests: Deploy test pods using generated RuntimeClasses

  - Resource Tests: Verify resource requirements are enforced