Add windows userdata

* refactor cloudinit packages to include support for windows userdata
* fix NewMachineConfig to store corect paths when on windows
* removed dependency on 7zip (python distribution installed by cloudbase-init has the tarfile module)

PR summary
==========

This pull request refactors the way userdata gets generated. It adds an interface to replace the cloudinit.Configure(), ConfigureBasic() and ConfigureJuju() bits. It also adds an interface to do platform specific rendering of path creation and file creation.

As a result of the new interface approach, there is a need to know the series for which we are rendering the cloudinit config before we reach ConfigureJuju. Because of this need, the Tools field either has to be populated in NewMachineConfig, or a new Series field needs to be added at that time. Given that the provisioner already knows this information when calling NewMachineConfig(), I see no reason to throw away this information and rely on a second structure, that is populated later (Tools) to determine the series (I am open to suggestions though). 


strawman:

 - we should introduce an `instance/setup` package, and put the current `environs/cloudinit` package in there, with `MachineConfig` renamed to `InstanceConfig`.
 - that package should also include the `Renderer` interface definition
 - FWIW, rather than the switch in `NewRenderer(series)`, I slightly favour a registry in the `instance/setup` package: implementations register themselves in their `init()` funcs, and those registrations are controlled by an `all.go` that imports the ones we want
 - add subpackages: `instance/setup/windows` and `instance/setup/ubuntu`, each of which defines a suitable `Renderer`, and contains *all* the os-specific code
 - the use of cloudinit itself is os-specific, really -- so the `cloudinit` package wouldn't know anything about rendering, because it would just be a dumb vessel into which the renderers can write suitable commands. We're somewhat lucky that we have cloudbaseinit, which lets us reuse the common cloudinit code on windows as well -- but I still don't think we should be assuming the use of cloudinit anywhere: it should purely be used an an internal implementation detail of the OS-specific renderers, and not leak out into method signatures.