Extract kube::config to kube-config crate?

[kazk]

After #696, kube::config doesn't depend on anything from kube-client. Should we make a crate? I think kube-config will be useful for some projects, and we can remove the awkward feature flags in kube-client.

By the way, I just noticed Config is not doing anything async, and can be made sync.

[clux]

Personally, I am hesitant towards this now because of the tiny costs it adds everywhere:

• another crate in the dependency tree for (generally) everyone (except the small subset of people who can already solve it with features)
• increases the impression that kube or kube-client is a much heavier crate than it is ("i need to compile 3/6 crates for this?")
• more cargo toml to manage
• slower publishing cycles (6 crates where we can break docs builds)

There's already a nice mapping now between kube-client and client-go (both including a config within underneath), and i think there's some value in maintaining that.

[clux]

By the way, I just noticed Config is not doing anything async, and can be made sync.

Yeah, I think that makes sense. It's doing some fs::read calls technically, so it's arguable that it should even be as sync as it is, but you have to read the config at the start of your program anyway (right?).