Add stacked KUBECONFIG support

[kazk]

• Cleaned up config::util
• current_context in KubeConfig is now Option<String>
• File paths in Kubeconfig are now remapped to absolute path after reading to support relative paths in stacked config. Assumes paths are unicode (should be fine because Go doesn't have OsString concept).
• Kubeconfigs are fully merged according to https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/#merging-kubeconfig-files even if kube only needs current_context, contexts, clusters, and auth_infos. If we don't need them, we should remove other fields from Kubeconfig as well because it'll be misleading. I think it's fine to keep.
  • For Option<Preferences> and Option<Vec<NamedExtension>>, we're just taking the first Some because it's unclear what should be done.
• Returns error when apiVersion/kind is set and mismatches. Not sure if this is correct behavior.

Closes #132

[clux]

delimit comment + option nits

looking great. you are really cleaning up the place.

[clux]

This feels like the type of thing where extensions should be Vec<String> with [serde(default, skip_serialize_if = "Option::is_none")] rather than Option<Vec<String>> since we treat missing as empty anyway.

Though it seems we have a convention for Option<Vec<.>> atm so it's a bit of a breaking change 🤔

[kazk]

I think it's good enough now. I'll merge after cleaning up the commits.

[clux]

looking great. got tests, super readable now.
there's enough to make a new release with this, are you at a good point for 0.50.0?

[kazk]

Yeah 👍 I don't think there's anything else I'd like to include in the next release and want to unblock users with this fix.

[kazk]

you are really cleaning up the place.

@clux Thank you for being receptive and quick to respond. It's been a pleasure to work on kube.

I know I went a little crazy the past week :) hyper + tower got me excited, and I wanted to do some clean up while I was off from work.
I'm back to work now, but will start implementing a project using kube (client and controller). Maybe I'll explore unit testing approaches for clients. Now with tower, it should be possible to create a fake like in client-go by creating a mock from resources and using that to create a client. Maybe kube-test crate can provide some convenience builder for it.

[clux]

It's been amazing. The huge hyper/tower hotswap, connection upgrading, tls rewrites, config rewrites, plus all the other hard stuff you've tackled like websockets subresources and schemas.

Really appreciate all the work you've done here. It's made the library a lot more usable and the rust kubernetes story a lot more attractive (even the crd reception was huge). Looking forward to hearing what issues you uncover on the controller side. I am back at work now as well, but reviewing your prs has been the easiest thing to do on the side, always happy to look at more :-)