Make pkg/util/k8sutil functions private or internal

[ericchiang]

If this isn't intended to be used by consumers we probably shouldn't allow them to use it. It's just extra API that needs to be maintained.

[ericchiang]

cc @hasbro17

[ericchiang]

pkg/generator and pkg/k8sclient should also be made private.

[hasbro17]

Agreed, we're planning to do an overall revamp of the the SDK APIs and objects and move away from maintaining global state and functions.
And making all of the internal utils private would be part of that.

[ericchiang]

cc @Verolop

[hasbro17]

Blocked by #169

[pawelprazak]

IMHO most important functions in pkg/k8sclient should be "configurable", as in an interface that can have a custom implementation, something like a "kubeclient factory", that would allow an SDK user to implement features like #351

[hasbro17]

After #382 we've removed the k8sutil and k8sclient helper functions that weren't supposed to be exposed as an API to users.

@pawelprazak I've addressed how the custom client functionality needed by #351 can be added on the PR.

pkg/generator is now pkg/scaffold whose utils are mostly internal now.
But there is something to be said for making pkg/scaffold completely internal since that's not something the SDK users need to see as a potential API(not that anyone has done so far). It's only needed by the SDK CLI in cmd/....
@estroz WDYT? We can follow that up in a separate issue though since this one was mostly related to the unnecessary client helpers we exposed initially.

[estroz]

@hasbro17 good point. There are no use cases for exposed pkg/scaffold code apparent to me. Every package in pkg should be exposed to users, so I think it would be worth moving pkg/scaffold -> internal/scaffold.

[hasbro17]

@estroz Can you please open a new issue for that. I don't think it's urgent but it'll be a big change, so it's worth discussing any potential issues with making all the scaffolding internal.