Kind: Internal APIs should not be exposed

[BenTheElder]

What happened:

• The internal API version is both public and expected to be used when using kind as a library. Neither of these should be true.
• Basically all of our library code is unstable and importable. We're running into the same problem as Kubernetes here where people are depending on packages that are not intended for public consumption (silly example: the CLI spinner). We need to clarify this so we can actually follow semver with our public APIs as we move to beta.

What you expected to happen:

• Public APIs should be intended for consumption and moving towards stability.

Anything else we need to know?: @munnerz and I have been discussing what to do about this for a while. Recent uptick in references to kind as a library suggests we should actually fix this.

/assign
/priority important-soon

[BenTheElder]

https://github.com/kubernetes-sigs/kind/pull/737 was a big fix for this

[BenTheElder]

Next up: The public types package should contain _all_ of the types, no importing types from other packages. This is hostile to the library user (can't see the API types when looking at the docs without hopping to another file just to read one type), and couples the public API versions to types controlled by non-API packages.

[BenTheElder]

patch types were moved into the config types spec.

[BenTheElder]

"CRI"-ish types still need to be moved inline to the config versions. Waiting till after I land the bigger container interaction refactor...

[BenTheElder]

will handle in refactors after https://github.com/kubernetes-sigs/kind/pull/1023 lands

[BenTheElder]

CRI part is done in #1023
remaining major public API fixup is in #1025

[BenTheElder]

this is more or less done