Makes deployment pipeline more modular

What does this MR do and why?

Add some option to enable / disable some part of the deployment-pipeline.

This is a first step to be able to have more modular pipelines.

What we have in mind is:

1. Pipeline that will perform only management deployment + rolling upgrade ( !2844 (merged) )
2. Pipeline to only deploy workload cluster on an existing management cluster
3. quick variant without any update? etc..

Remove ONLY_DEPLOY_MGMT: variable as it only address one specific usecase and replace it with 4 variables

  DEPLOY_MGMT_CLUSTER: "true"        
  DEPLOY_WORKLOAD_CLUSTER: "true"
  UPDATE_MGMT_CLUSTER: "true"
  UPDATE_WORKLOAD_CLUSTER: "true" 

each one controlling a specific job. Change the rules to stay coherent as for example the update of a cluster need to happens after the deployment etc...

Create 2 rules set that can be reuse in test definition for example:

.rules:need-management-cluster:

.rules:need-workload-cluster:

for most of the cases they should be sufficient, but for some case we need to write our own.

---

Missing parts:

to be complete, we should change the way to retrieve the management-cluster-kubeconfig , to be able to either retrieve it from the artifact of the deploy job or use a remote file (probably located with ci values). I'll address this point in a separate MR that will introduce new pipelines to test workload deployment on long live management cluster