Add Crossplane provisioner for Keycloak

What does this MR do and why?

Following !2976 (merged) which introduces the Crossplane unit, this MR adds the Keycloak provider and configuration units for it. Note, that this does not add the keycloak resources to actually start manage everything, that will come in a different MR although the code introduced here configures the provisioner making it ready to interact with the existing keycloak instance.

This MR adds some new units:

• crossplane-provider-keycloak

- crossplane-provider-keycloak-config

crossplane-provider-keycloakinstalls the provider-keycloak via DeploymentRuntimeConfig and a Provider resource.

Additionally it grants permissions to the crossplane-system ns to access the keycloak secret store.

Crossplane-init unit gets some extra files that creates all the needed secrets using ESO in the crossplane-system namespace.

As pointed in !3104 (comment 2329502992) , i've also disabled the networkpolicy for the time being, as it doesn't quite work with how XbuiltinObjects work and blocks the requests.

Initially we were going to rely also on some compositions and functions to get some of the keycloak builtin objects, along with a separate python script that would run as a job to get the UUID's of the builtin objects.

In the meantime however, the provider-keycloak got some new and shiny functions, allowing us to get rid of the extra headache with custom scripts and extra functions and compositions.

Related reference(s)

Depends on !2976 (merged) Closes #2186 (closed)

Test coverage

Currently , the first commit contains the changes from 2976, and the second commit will contain these specific mr's changes.

CI configuration

CI pipelines perform an update for both management and workload clusters, this update will NOT perform a ClusterAPI rolling update (deletion and creation of new K8s nodes) by default.

For some cases, it may be relevant to perform more complex tests.

Theses features can be activated in an MR by adding one of these labels to the MR and will apply to the next pipelines.

• adding the label ci-featuretest-rolling-update pipelines will perform a node rolling update in the -update jobs (without version upgrades)
• adding the label ci-featuretest-upgrade-from-1.1.1 pipelines will perform an upgrade from Sylva 1.1.1 to your dev branch (including a k8s version upgrade resulting in a node rolling update)