Improve file layout for generated types

[matthchr]

Describe the current behavior
Today we lay the files out with all the methods for types in the same file as the types. ARM types are in the same package as the Kubernetes types. It's a bit messy.

Describe the improvement
The following ideas were discussed:

1. Move ARM types into a subpackage
2. Possibly split types from methods on types - or maybe just some of the methods on types (i.e. defaulting stuff could go into its own file?)
3. Combine spec and status types for the ARM types?

[theunrepentantgeek]

I strongly prefer keeping methods in the same file with the associated types - a legacy of having to play far too much mystery file exploration on prior projects, hunting for the implementation of a particular method to see what it does (and this was in C# projects where I only had to contend with partial classes and extension methods, and I had Visual Studio for navigation, not Go where literally every function can appear somewhere different in the package).

I agree with moving the ARM variants into a subpackage, as that makes it clear that they're an implementation detail that can be ignored by other consumers of the types.

I thought our file-type allocation approach was to start with a resource and put all the types it references into the same file - so I wonder why we're getting Spec and Status types elsewhere.

[theunrepentantgeek]

Can we move the ARM types into a subpackage?

The API types need to reference the ARM types when they implement CreateEmptyARMValue() and related conversion routines.

Is there anything on the ARM types that requires referencing the API ones?

[matthchr]

@theunrepentantgeek AFAIK no, there should not be references from the ARM types to the Kube types. The ARM types are the "SDK" for interacting with Azure and should in theory be able to stand alone.

[theunrepentantgeek]

We are still interested in improvements here.

@Porges suggested moving the spec and status types into separate subpackages, which would also allow us to simplify type naming.

[theunrepentantgeek]

Still interested.

[matthchr]

This isn't super critical but it's something we're still tracking

[matthchr]

Moved this into 2.3 as it's related to some work that @theunrepentantgeek is working on. We may want to update this and/or close it and make a more focused item for work that we have remaining after the upcoming changes.

[matthchr]

No change from the above

[matthchr]

We've moved this into 2.8.0, it seems like it should be pretty easy now with the infrastructure work that @theunrepentantgeek added.

[theunrepentantgeek]

I've split the remaining work into new issues.