Consider adding toleration for os=Windows taint

[peterbom]

It appears to be standard practice to add taints to Windows nodes in mixed-OS clusters, to prevent Linux pods from being inadvertently scheduled to Windows nodes. See guidance here and here.

Issue #180 describes one such situation in which that configuration existed, which caused Periscope not to be deployed to the Windows node, because it did not have the corresponding toleration.

Question: Should the Periscope deployment always add a corresponding toleration, just in case the cluster it is being deployed to has that taint on its Windows nodes?

Some initial thoughts:

1. There does not seem to be a 'standard' key for the taint (I've seen variously "os", "kubernetes.io/os" and "node.kubernetes.io/os"). Including a toleration for just one would seem arbitrary; including tolerations for them all would seem excessive, and still might not cover all real-world scenarios.
2. There may be other ways for users to add the necessary tolerations, without them needing to depend on the Periscope tool updating its deployment spec. For example, GKE uses an admission webhook to automatically update pods using Windows containers.
3. Different users/organizations might use different approaches for addressing this scheduling problem. For example, a similar effect could be achieved using affinity/anti-affinity rules. Adding a toleration in these circumstances would not be helpful.

@Tatsinnit - any thoughts to add to this?

[peterbom]

Another angle for addressing this might be to improve the documentation around 'manual' deployment (i.e., Kustomize). This ended up being the 'workaround' provided for #180 but might in fact have been the most appropriate approach anyway.

There might always be cases where customers want to tweak the deployment in some way that's specific to their cluster. The ability to do that is a core feature of Kustomize, and part of the reason we moved towards that means of deployment.

Our main README currently focuses only on the az CLI. This emphasis is biased against users who:

• (a) want complete control and transparency over their interactions with their cluster (for whom kubectl/kustomize might be preferred); or
• (b) want the ease and simplicity of GUI/single-click based deployments (for whom the VS Code extension might be more appropriate).

cc @Tatsinnit, who has also been looking into updating the docs.