[BUG] Delete problems with Flux HelmRelease objects which are managed through component-operator-runtime

[cbarbian-sap]

Describe the bug
Flux HelmRelease objects which are dependents of components (that is, instances of components.core.cs.sap.com) are sometimes inconsistently deleted; that means, the HelmRelease disappears after deletion, but the dependent objects of the HelmRelease remain in the cluster.

Tested with Version
component-operator: v0.1.26
component-operator-runtime: v0.3.84

To Reproduce
Create a Component containing a HelmRelease and delete the component; sometimes, the dependent objects of the HelmRelease survive (but Component and HelmRelease are gone).

Expected behavior
The HelmRelease should be properly deleted including all its dependent objects.

[cbarbian-sap]

This seems to be similar to #265.

Checking deeper, it turns out that (if the effective update policy is SsaOverride), then we reclaim fields owned by field managers whose name starts with kubectl or helm (see here). Now, unfortunately, the flux helm-controller uses helm-controller as field owner name (which matches that list of prefixes for reclaimed fields). Thus we are going to claim ownership of the finalizer added by flux, and (since our intended manifest does not contain any finalizers, obviously) we will remove the finalizer; of course, flux will add it back timely. But if the deletion happens right inbetween, the HelmRelease has no finalizer, and will therefore be dropped immediately, without giving flux a chance to reconcile the deletion (means, to delete the dependents).

Probably, helm should be removed from the list of specially treated field managers.

[cbarbian-sap]

In general, the list of reclaimed field managers should be made configurable (on reconciler, and on component level); created #269 for this.