pkg/virt-config/featuregate refactor to avoid CF conflict hell

[Lee Yarwood]

Hello folks,

I raised this issue when requesting a CF extension for VEP 172 [1] and
sacrificed a small number of tokens while refactoring the package to hopefully
avoid the same CF conflict hell in the future.

featuregate: split into SIG sub-packages to reduce merge conflicts
https://github.com/kubevirt/kubevirt/pull/18176

The motivation is twofold:

1. **Ownership clarity** — each gate file declares its owning SIG and
maintainer, and lives in the corresponding package. This makes it
straightforward to identify who is responsible for progressing a gate
through its lifecycle.

2. **Reduce contention on shared files** — today all gates are registered
in two large files (`active.go` / `inactive.go`). Any new gate or
state change touches those same files, leading to unnecessary merge
conflicts. After this refactor each gate is a self-contained file with
an `init()` registration, so additions and progressions are isolated.

The refactor is purely structural with no behavioral changes to the feature
gate evaluation logic. The `IsEnabled()` precedence, lifecycle states,
and KubeVirt CR configuration surface are all unchanged. The series is
three commits:

1. Add `ConfigReader` interface and SIG sub-packages with per-gate files
2. Migrate all consumers to import from the SIG sub-packages
3. Embed SIG grouping structs in `ClusterConfig` and remove the old files

I've also included a contributor guide at `docs/devel/feature-gates.md`
covering how to introduce new gates and progress existing ones under the
new structure.

I'd appreciate reviews and feedback on the approach. I'd also like to
ask whether the community thinks this warrants a VEP, or whether the
scope (internal refactor, no API/behavior changes) is small enough to
proceed without one.

Cheers,

Lee

[1] https://groups.google.com/g/kubevirt-dev/c/hhcMZ0MHm6k