Refactor K8ssandraCluster deletion cleanup operation

[adejanovski]

In controllers/k8ssandra/cleanup.go we delete all the objects that are tied to a deleted K8ssandraCluster object.
The deleteDeployments(), deleteServices() and deleteConfigMaps() could benefit from the following improvements:

• Combine them into a generic function/method if possible
• Move a few function arguments to the K8ssandraClusterReconciler object in order to reduce their number in the calls
• Evaluate the possibility of returning a more meaningful object than a boolean, which could carry more information (such as an error or a ReconcileResult)
• make use of DeleteAllOf, using the labels in the LabelSelector, instead of looping over objects to delete
• Write unit tests for it

[olim7t]

Note: this is closely related to #961.

As I'm digging into the code I'm encountering more questions:

• there are two main methods: checkDeletion which handles the deletion of the whole cluster, and checkDcDeletion which handles a single DC (if it's been removed from the cluster spec). However they don't share any code, which feels like a wasted opportunity for reuse.
• case in point: checkDeletion removes Stargate, Reaper, deployments, services and configMaps. checkDcDeletion only removes Stargate and Reaper. Decommissioning a DC does indeed leave at least one configMap behind (tested on a very simple cluster, there's probably more in complex scenarios).
• checkDcDeletion looks up the components by exact name. checkDeletion deletes every cluster sub-component in the current namespace. This works now but is something we'll need to keep in mind if we factor the code (two DCs can exist in the same namespace, so we can't reuse the shotgun approach for decommission).
• the Stargate/Reaper deployments and services already use a controller reference for garbage collection. It looks like deleteDeployments and deleteServices were only added for Medusa. Why can't we use controller references there too?

In fact, I think we could generalize the use of controller references. As long as every remote object we create is owned by the CassandraDatacenter (directly or transitively), we shouldn't need to do anything beyond deleting the DC.
I'm going to experiment with that.