ensure baremetal server disks cleanup (kyverno policy to patch BaremetalHosts automatedCleaningMode)

Close : #1614 (closed)

Currently on Sylva the BMH disks are never cleaned.

As a reminder the automatedCleaningMode can be set on a baremetalHost, a metal3machine, and a metal3machineTemplate.
Actually, we were hoping that this clean would be performed during inspection (automatedCleaningMode=metadata on BMHs) and then deactivated when a metal3machine was assigned to the BMH (via automatedCleaningMode=deactivated on m3mT/m3m).
But in reality, as explained in the issue, the clean step is performed by Ironic after inspection when a host is assigned/provisioned on the BMH. At that precise moment, the automatedcleaningMode value/parameter taken into account is the one set on the m3m (inherited by m3mT), i.e. deactivated. If we set it to metadata on the m3m, then the disks will be cleaned at each rolling-upgrade, which we don't want.

The idea of this MR is to keep the default value on a baremetalHost, which is metadata (ie. "please clean disks"), and omit it on m3m and m3mT.
Thus, only the value from the baremetalHost will be taken into account. Once the first provisioning of the BaremetalHost has been completed, we will set it to disabled to prevent the disks from being cleaned during a rolling upgrade. \

This MR does not handle the case of deletion, as the clean is performed during deprovisioning. It is therefore complicated to know whether deprovisioning is due to a rolling-upgrade or a deletion (this seems easier to do directly via capm3).

From my point of view, this would merit an improvement/issue on capm3 side in order to properly manage this parameter in case of rolling-upgrade/node-reuse. In this case, disks must not be cleaned.

Related sylva-capi-cluster MR: sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!472 (merged)