Make the app.kubernetes.io/* labels user-settable again (regression of #480 in v1.6.0)

Since #517 (v1.6.0) the operator refuses these keys in `spec.labels`,
`spec.podMetadata.labels`, `spec.ownedObjectsMetadata.labels` and
`spec.serviceSpec.labels`:

app,
app.kubernetes.io/name, /part-of, /component, /instance, /version, /managed-by

For an instance whose CR carries one of them, the operator builds nothing: no StatefulSet, no Service, no PDB, no NetworkPolicy.

v1.4.0 put `component`, `instance` and `version` on the pods, and #480 made `name` and `part-of` settable in v1.5.0 (#446). All five are unavailable now.
This means, an update to v1.6.0 breaks *all* DragonFly clusters, which already defined these labels inside `spec.labels`, because the Operator now refuses to reconcile them. Furthermore, existing externally defined network policies won't apply to the pods anymore, because the labels changed.

These labels say how a workload fits into the cluster it runs in, which the operator cannot know. They are designed to be managed by the cluster users. Many business clusters use these recommended labels for a standardized purpose, e.g. logging. This means, these labels strictly MUST appear in these clusters on any resources according to the policy of the company, including resources managed by operators.

Defaulting them is useful, reserving them is not. `managed-by` is the exception, `dragonfly-operator` is the right value there.

When operators need some specific labels for their internal operation (e.g. for their selectors or for pod identification when pods are managed by the operator itself), the operator can define their own (namespaced) labels, e.g. something like `dragonflydb.io/instance`

Two additional consequences arise from this topic:
1. There must be a clear migration path for a change on label behavior (for example, new incompatible behavior can be activated using an operator setting. Cluster users can ensure all existing Clusters are prepared for a change, then switch on the new behavior. The new behavior can be made a default in the operator version after that). If you need any assistance here, let me know
2. These kind of changes are breaking changes and should be marked as such in the changelog

Trace validation and reconciliation for labels in spec.labels, spec.podMetadata.labels, spec.ownedObjectsMetadata.labels, and spec.serviceSpec.labels, then inspect how StatefulSets, Services, PDBs, and NetworkPolicies receive them. Done means the listed user labels are accepted and propagated, managed-by keeps its operator value, and the breaking behavior and migration path are documented in the changelog.

Written by the indexing model from the issue text.