feat: Controller that copies ClusterClasses to namespaces

[dlipovetsky]

What problem does this PR solve?:
A Cluster must be in the same namespace as the ClusterClass it references (see kubernetes-sigs/cluster-api#5673).

This PR adds a controller that copies any ClusterClass (and the Templates it references) found in a source namespace (default by default) to every "target" namespace, i.e. a namespace that has a well-defined label key (caren.nutanix.com/namespace-sync). The controller does not update or delete the resources in a target namespace.

Which issue(s) this PR fixes:
Fixes #

How Has This Been Tested?:

This PR adds envtest-based integration tests that verify that the controller:

1. Copies ClusterClasses to a newly-created target namespace.
2. Copies a newly-created ClusterClass to target namespaces.
3. Does not update resources in a target namespace.

Special notes for your reviewer:

This PR includes a modified copy of the Cluster API internal test framework.
The namespacesync controller reads and writes Templates of various types. The
upstream test package creates "generic" Template types and CRDs. This allows us
to test the controller using envtest, with real types and CRDs.

TODO

• Expose "source" namespace name in the helm Chart values
• Decide the label key to use for target namespaces (right now, it's caren.nutanix.com/namespace-sync)

[dlipovetsky]

Black duck check fails due to issue fixed in #716.

[jimmidyson]

I'm wondering if it would be simpler to just use one (or all) of the provider CRDs that are already present as dependencies?

[dlipovetsky]

I did try to use the existing code in test/helpers, but ran into various issues. For example, that code will not configure a controller.

Reusing the existing code is still my plan, but I want to do that in a future PR, because this is this PR introduces a new use case (a controller), and I want some signal before I make changes to the existing code.

I also wanted to use the "generic" CRDs, because I don't want to tie the tests to a specific infra provider.

I'm going to ask that the upstream package to create the "generic" CRDs be moved out of internal, because it's useful to a project, like CAREN, that implements controllers that work with Templates.

[dkoshkin]

Its a shame we need to import all the internal/test stuff, just left a nit comment about having some tooling to sync that.
Everything else looks great!

[dlipovetsky]

I will address the two TODOs in a separate PR:
1.Expose "source" namespace name in the helm Chart values
2. Decide the label key to use for target namespaces (right now, it's caren.nutanix.com/namespace-sync).