Provide a better API for aggregtes and traits instead of annotations on a Node

[fwiesel]

Spawned from #186.

Currently, we set annotations and labels in the shoot spec, which are then used by the operator to configure the hypervisor-spec and therefor the operator.
The downside is, that this ties the configuration to a worker-pool.

Examples:

• We wanted to introduce hana only nodes, which are defined by a trait. We do not have enough hardware to do so on the whole workerpool, so we had to split up the pool, i.e. redeploy part of the pool just to get the trait in.
• We might want to have a configuration for a whole hardware class and that might be spread over different worker pools (i.e. building-blocks), which requires us to replicate that configuration into these annotations.
• We might want to have exceptions to these rules, such a certain building-block might needed to be treated differently,
• Or an operator (or developer) might want to set a value on an individual node for highly specific reasons.

[fwiesel]

If annotations are propagated after node creation, we should find a better way to handle manual changes to the hypervisor CRD instead of "overwriting" everything. Is it possible that the managed fields api helps us there?

Here a (shortened) version:

- apiVersion: kvm.cloud.sap/v1
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      .: {}
      f:aggregates: {}
      f:createCertManagerCertificate: {}
      f:evacuateOnReboot: {}
      f:highAvailability: {}
      f:installCertificate: {}
      f:lifecycleEnabled: {}
      f:reboot: {}
      f:skipTests: {}
  manager: manager
  operation: Update
  time: "2025-12-01T20:16:06Z"
- apiVersion: kvm.cloud.sap/v1
  fieldsType: FieldsV1
  fieldsV1:
    f:spec:
      f:maintenance: {}
  manager: kubectl-edit
  operation: Update
  time: "2025-12-01T21:07:12Z"

I think, the more important question than if we can is if we should allowing people to edit arbitrary fields manually and maintaining that configuration is really desirable. That screams config drift.

One thing is the maintenance field, which is not managed by the hypervisor-controller, but aggregates and traits, are well-defined in the annotations.

If you do not want them to be reconciled, the solution is straight-forward: Remove the annotation. That is in my mind also the migration path away from them to something else.

But I think. it needs to be a more structured way, ideally allowing us "layering" configurations. I.e something like "HypervisorConfigSet CRDs, that allow one to define config values for a subset of nodes, and possibilities to override them.

In summary, I think, we need clear responsibilities of the "ownership" of a field, and ideally it should raise an error, if there is conflicting requirements.