Feature Proposal: Nested NodeFeatureGroups

**What would you like to be added**:

Add support for nested `NodeFeatureGroup` objects.

A `NodeFeatureGroup` should be able to include the effective membership of other
`NodeFeatureGroup` objects by name. The proposed API adds an optional
`containsGroups` field under `spec.featureGroupRules`, and exposes referenced
groups in status through `status.groups` together with a total
`status.nodeCount`.

For example, a group may directly match nodes with PCI vendor `b` and also
include an existing `vendor-a` group:

```yaml
apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeatureGroup
metadata:
name: vendor-a
spec:
featureGroupRules:
- name: vendor-a-devices
matchFeatures:
- feature: pci.device
matchExpressions:
vendor:
op: In
value:
- "a"
status:
nodeCount: 4
nodes:
- name: worker-a-01
- name: worker-a-02
- name: worker-a-03
- name: worker-a-04
---
apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeatureGroup
metadata:
name: vendor-ab
spec:
featureGroupRules:
- name: vendor-b-devices
matchFeatures:
- feature: pci.device
matchExpressions:
vendor:
op: In
value:
- "b"
- name: include-vendor-a
containsGroups:
- vendor-a
status:
nodeCount: 7
nodes:
- name: worker-b-01
- name: worker-b-02
- name: worker-b-03
groups:
- name: vendor-a
```

The effective membership of `vendor-ab` is the union of the directly listed
nodes and the effective membership of `vendor-a`.

**Why is this needed**:

Today, `NodeFeatureGroup` materializes matching nodes as a flat list in
`status.nodes`. As clusters grow, that status can become very large for groups
that match many or all nodes.

Kubernetes node names may be up to 253 characters, and cloud provider instance
names commonly range from 63 to 128 characters. etcd defaults to a maximum
request size of 1.5 MiB, which can fit only about 12k raw 128-character node
names before JSON serialization, metadata, managed fields, and status overhead
are included. Existing clusters can already exceed this scale, so a broad
`NodeFeatureGroup` may eventually fail to fit in a single stored object.

Nested groups reduce this risk by allowing reusable groups to be referenced
instead of duplicating all of their node names into every composed group. This
also keeps `NodeFeatureGroup` objects smaller, reducing apiserver, etcd,
informer, and scheduler I/O for large clusters.

No implementation files or tests are named in the issue. Start by tracing the NodeFeatureGroup API and its status handling, then define how containsGroups, status.groups, nodeCount, unions, and nested references should behave. Done means nested groups are supported without duplicating all referenced node names in composed status.

Written by the indexing model from the issue text.