Find a unique type name by appending indexes

[turkenh]

Description of your changes

Fixes #135

I have:

• Read and followed Crossplane's contribution process.
• Run make reviewable to ensure this PR is ready for review.
• Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

With provider-tf-gcp by generating all resources.

[muvaf]

I wonder if we can get away with appending the CRD kind name repeatedly. Instead of SubnetworkParameters2, how would SubnetworkParameters_Subnetwork or Subnetwork_SubnetworkParameters look? Feels like because they are in the same package, it's kind of too easy to confuse the one used by one resource with the other when it's only a number that differentiates them.

[turkenh]

Given this is just generated code and we don't expect anyone to deal with modifying those types, I prefer numbers.
One case could be people importing these types to interact programmatically but still, in that case, I believe using the wrong type would cause compilation errors hence easy to figure out.

Even if we go with appending the kind name as you suggested, we will still have both SubnetworkParameters and SubnetworkParameters_Subnetwork in the same package and the former would belong to RouterNat resource instead of Subnetwork which is still confusing.

[muvaf]

I was thinking about someone importing this package and using the types rather than modifying. In such cases, the types being generated or not doesn't really matter for them and Go types having numbers in the name doesn't look very idiomatic. I'm OK with both approaches though.

[turkenh]

@muvaf your comments got resolved!

[muvaf]

I don't have a great suggestion but Generated/types.Generated feels too generic.

types.TypeTree

Suggested change

	// Generated stores the information of the generated types
	type Generated struct {
	// TypeTree contains all the types and their sibling relations.
	type TypeTree struct {

types.CustomResourceDefinition

Suggested change

	// Generated stores the information of the generated types
	type Generated struct {
	// CustomResourceDefinition includes all Go types necessary to print a CustomResourceDefinition Go struct.
	type CustomResourceDefinition struct {

types.Managed

Suggested change

	// Generated stores the information of the generated types
	type Generated struct {
	// Managed includes all Go types necessary to print the Go structs for a Managed resource.
	type Managed struct {

[turkenh]

I cannot claim that types.Generated is great but I couldn't find a better alternative and honestly would prefer it to the alternatives you suggested above :)

I believe it is not that bad and actually conveys its purpose: types.Generated is a struct that holds Generated types

[muvaf]

LGTM! It'd be great if you can add tests for generateTypeName.

[turkenh]

LGTM! It'd be great if you can add tests for generateTypeName.

@muvaf indeed I attempted to add but postponed to a larger refactor since I wanted to change the function signature as follows for easier testability:

- func (g *Builder) generateTypeName(suffix string, names ...string) (string, error) {

+ type lookupFunc func(name string) types.Object
+ func generateTypeName(lookup lookupFunc, suffix string, names ...string) (string, error) {

If this sounds ok to you, I can add unit tests with that.

[muvaf]

@turkenh you can actually mock the package and its scope like the following without changing the signature: https://github.com/crossplane/crossplane-tools/blob/fa70b84/internal/method/resolver_test.go#L229

[turkenh]

@muvaf added unit tests without changing the function signature.