External operators can't import v1 API types as types and merge logic live in the same package as busines logic

Problem

The CRD types in pkg/apis/clickhouse.altinity.com/v1 live in the same Go package as the controller's template-merge business logic (type_templates.go, type_chi.go, type_configuration_chop.go). That logic depends on mergo.WithSliceDeepMerge, an option that only exists in a personal fork (github.com/sunsingerus/mergo).

Because Go compiles every file in an imported package, anyone importing your v1 types is forced to mirror this replace directive in their own go.mod

replace (
	github.com/emicklei/go-restful/v3 => github.com/emicklei/go-restful/v3 v3.10.0
	github.com/golang/glog => github.com/sunsingerus/glog v1.0.1-0.20220103184348-48242e35873d
	github.com/imdario/mergo => github.com/sunsingerus/mergo v0.0.0-20230507185449-fc6fffa94450
)

Adopting a personal fork as a transitive dependency or forcing a replacement of large upstream project is undesirable for any consumer project. The consequence is that external operators that build on CHI/CHK resources fall back to unstructured.Unstructured, losing compile-time type safety.

Proposal:

Move the merge logic into an internal package, leaving pkg/apis/clickhouse.altinity.com/v1/ containing only:

• struct definitions (with kubebuilder:object markers)
• generated deepcopy methods
• scheme registration

This is the standard Kubebuilder layout. The operator reimports both packages so zero behavior change.
Happy to submit a PR if the proposal is approved.

previous issues: https://github.com/Altinity/clickhouse-operator/issues/1618

Review pkg/apis/clickhouse.altinity.com/v1 and the named type_templates.go, type_chi.go, and type_configuration_chop.go files first, then trace their mergo-based merge dependencies. Done means the v1 package contains only API definitions, generated deepcopy methods, and scheme registration, while the operator imports a separate internal merge package without changing behavior.