WIP: refactor create command and add macos qemu support

[Orzelius]

Refactor cluster create logic

Previously a large chunk of the cluster create logic took place in the long create() function in which it was hard to tell which parts are applicable to qemu, docker or both. Adding a third provider (macos qemu) would have complicated matters even more so I decided to refactor the logic in the aim of clearer separation of concerns and better maintainability.

• Extract common logic from the create function and split the rest into CreateDockerCluster and CreateQemuCluster
• Create create qemu and create docker sub commands commands, which show only the applicable flags
• Validate if non applicable flags are passed to the top level create command (e.q. qemu only flag is passed when docker provider is used)
• Only pass applicable options to the create logic
• Create common requests types and qemu (vm) and docker specific request types so it's clear what each provider expects for input and is able to provide.

Add macos qemu provider

qemu works macos with the only big difference being the networking setup. Current (linux) qemu logic uses CNI plugins to set up the network but that will not work on macos.

The best solution I've found thus far for configuring the network on macos is to use apple vmnet which is also supported in qemu. AFAIK vmnet or any other networking solution for macos don't support nearly the same level of configuration as linux networking tooling. I've outlined the differences in networking capabilities in the relevant request types (common, linux, macos) As you can see most of the network parameters would not be supported on macos, but it will still suffice for testing and development needs which don't require complex networking. The resulting stack would look something like this:

source and more info: https://gist.github.com/max-i-mil/f44e8e6f2416d88055fc2d0f36c6173b

The biggest problem with this approach is that there doesn't seem to be a way to assign IPs to the vms. IPs seem to be assigned semi randomly by apple DHCP somewhere within the requested CIDR. Current qemu logic assumes IPs to be known from the very beginning, meaning that a significant part of the logic has to be adapted to the scenario where IPs are known only after the VMs have started.

[Unix4ever]

I'd propose to create an issue in the Talos repo first instead of submitting the PR.