[module-sdk] feat: delete workloads by name or selector

[fuldaxxx]

Description

common-hooks/storage-class-change can now find the workloads to delete by label
selector instead of a single hardcoded name.

Args.ObjectName	Behaviour
set	Exactly that object is deleted. A delete error other than NotFound is logged and the hook still succeeds — unchanged, long-standing behaviour.
empty	Every object of Args.ObjectKind in Args.Namespace labelled Args.LabelSelectorKey=Args.LabelSelectorValue is deleted. A delete error other than NotFound fails the hook; an empty match is only warned about.

No new fields in Args: the selector already used for the pvcs/pods snapshots is
reused. ObjectName always wins over the selector, so every module that configures
both (all of them today) keeps the current behaviour and the new branch is
unreachable for them — the change is backward compatible by construction.

Deletion is now issued through the dynamic client for all supported kinds, so
switch over ObjectKind that built typed objects is gone. For StatefulSet and
Deployment this is the same REST request as before; as a side effect the wh
deletion path became reachable from the test framework, whose fake cluster is the
dynamic one.

Tests: four new framework tests covering deletion by selector (including that
non-matching objects survive), deletion by name, an empty match, and a failing
delete. All four fail on the previous implementation.

Why do we need it, and what problem does it solve?

The hook deleted the workload strictly by ObjectName. A module that owns several
workloads in one namespace — for example StatefulSets with generated names —
only one of them deleted. The survivors kept their old volumeClaimTemplates, and
the following Helm release failed:

StatefulSet.apps "..." is invalid: spec: Forbidden: updates to statefulset spec for
fields other than 'replicas', 'ordinals', 'template', 'updateStrategy',
'revisionHistoryLimit', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds'
are forbidden

which leaves the module release stuck in a retry loop and the storage class change
half-applied: some workloads on the new class, the rest on the old one.

Verified on a live cluster with a test module that deploys two StatefulSets i
namespace, switching the default storage class between two classes:

• with ObjectName set — one object deleted, the second one stayed on the old
  storage class, Helm failed with the error above;
• with ObjectName empty — both objects deleted in one hook run, both recreated
  with the new storage class, no Helm errors.