Fix type collisions in the same CRD package

[muvaf]

This PR adds order for the iteration by sorting the keys and produce every type it encounters. If there is a name collision we add the former field name until we find a unique name, which is guaranteed. In the above example, we'd have one TimeoutParameters type and the second one would have TcpRouteTimeoutParameters name. Since we sort, always the same type will get to have a prefix.

Fixes #23

[turkenh]

@muvaf just gave this a try and noticed that it is working as you described.

But I am wondering if there could be a way to detect and reuse same structs instead of duplication with exact same fields.

For example, checking apis/emr/v1alpha1/emrcluster/zz_types.go generated with this and we have a couple of EbsConfigParameters which are exactly identical. Couldn't we somehow figure that out and reuse it if this is the case?

type EbsConfigParameters struct {
	Iops *int64 `json:"iops,omitempty" tf:"iops"`

	Size int64 `json:"size" tf:"size"`

	Type string `json:"type" tf:"type"`

	VolumesPerInstance *int64 `json:"volumesPerInstance,omitempty" tf:"volumes_per_instance"`
}

...

type MasterInstanceGroupEbsConfigParameters struct {
	Iops *int64 `json:"iops,omitempty" tf:"iops"`

	Size int64 `json:"size" tf:"size"`

	Type string `json:"type" tf:"type"`

	VolumesPerInstance *int64 `json:"volumesPerInstance,omitempty" tf:"volumes_per_instance"`
}

...

type CoreInstanceGroupEbsConfigParameters struct {
	Iops *int64 `json:"iops,omitempty" tf:"iops"`

	Size int64 `json:"size" tf:"size"`

	Type string `json:"type" tf:"type"`

	VolumesPerInstance *int64 `json:"volumesPerInstance,omitempty" tf:"volumes_per_instance"`
}

...

type InstanceTypeConfigsEbsConfigParameters struct {
	Iops *int64 `json:"iops,omitempty" tf:"iops"`

	Size int64 `json:"size" tf:"size"`

	Type string `json:"type" tf:"type"`

	VolumesPerInstance *int64 `json:"volumesPerInstance,omitempty" tf:"volumes_per_instance"`
}

[muvaf]

We could possibly reuse it but the one we need to reuse may not be the one named first. For example, ideally we'd like to use EbsConfigParameters every place possible as long as its structure matches. However, it could be slightly different than others and MasterInstanceGroupEbsConfigParameters might be the one that's common, so it'd use MasterInstanceGroupEbsConfigParameters type for, let's say, CoreInstanceGroupEbsConfig field which is sort of misleading.

Apart from that, we'd need to come up with an equality check for the types which is dangerous because even if the fields are same, their kubebuilder validation or comments could be different. So, I'd kind of feel safer with abundance of types given that Terraform schema doesn't do that optimization either, i.e. letting author specify a schema and refer to it from several places.

[turkenh]

LGTM!