First pass at shared validation

[dturn]

What are you trying to accomplish with this PR?
Consistent preflight validations for all tasks. Inspiration for this PR taken from https://github.com/Shopify/kubernetes-deploy/compare/config_validator

I've started by just adding this to restart task. If we like where this is going I can add it to the remaining tasks in this PR or subsequent ones.

How is this accomplished?

Our run/restart/deploy tasks have overlapping state they need, I've attempted to extract it into TaskConfig object. For now this is context, namespace, and logger. I've also added methods for generating kubectl, and kubeclient_builder, its possible that this is backwards and those methods should take a task_config. (We decided against generating kubectl, kubeclient_builder in task_config, see the comments for the discussion about why). When we go to Krane I think the TaskConfig should be passed to the task instead of it building it. (Though maybe not since that would require users using this as a library to construct a 'random' object, perhaps two constructors for each task).

I've also created a Validator object that can validate, kubeconfig, context, namespace and kubectl version. This looks to be the shared set of validations. Each task has additional validations, this PR leaves open several approaches to solving that problem.

What could go wrong?

Because we need to unify validations that are done slightly differently we are changing the error class that gets raised as well as the wording. If people were rescuing these errors or matching text this will be a breaking change.

[timothysmith0609]

A few small comments, but this looks ready to go once you address them.
Have you identified other parts of the code where we can start substituting in @task_config, or do you feel it's only really going to be worthwhile for the purposes of validation?

[timothysmith0609]

Noticed a few typographical things on this pass, but everything else looks good for me