Feature: draksetup modify-vm0 utility

[psrok1]

This PR introduces draksetup modify-vm0 command that allows to safely modify vm-0 state and rollback changes in case of failure. Right now documentation recommends drakplayground 0 which is very hacky way to modify VM and it's really easy to desynchronize snapshot of memory/CPU state snapshot.sav with storage contents. It usually leads to irreversible damage to the file system (due to unexpected errors resulting from buffers and file caching combined with changed file-system layout) and various issues that are really difficult to debug.

Command uses snapshot features that are already used by ZFS, LVM and QCoW backends. vm-0 modification consists of two phases:

1. (first phase) begin - vm-0 is started with preserved current state, so it's possible to rollback it to the state without modification that is synchronized with current snapshot.sav
2. (second phase) commit - changes in vm-0 storage are applied to the main snapshot, new snapshot.sav is made, VM state is restored to vm-1 and kernel/DLL profiles are recreated.
3. (alternative second phase) rollback - changes in vm-0 storage are reverted

Actual implementation depends on the storage backend:

• zfs storage backend already maintains a proper snapshot vm-0@booted, so we can safely modify vm-0 volume as all vm's originate on that snapshot. In case of commit: we delete vm-n storage state and create new vm-0@booted snapshot from current vm-0 state. In case of rollback: we're doing a rollback of vm-0@botted onto vm-0.

• for qcow storage backend we create vm-0-modify.img with vm-0.img as backing file, and then run vm-0 using vm-0-modify.img image. In case of commit we merge vm-0-modify.img with vm-0.img using qemu-img commit command. In case of rollback we just delete the vm-0-modify.img file.

• lvm storage backend is similar to the qcow case. We create a snapshot vm-0-modify that is then merged or deleted. LVM implementation had its own issues e.g. hardcoded 1GB size of a snapshot or vm-0-snap snapshot that have never been used. The second issue was fixed in this PR, the first one needs proper configuration field.

Other changes include:

• whole VM profile is made using function create_vm_profile and is made from vm-1. In case of vm-0 modification we need to regenerate kernel profile as well. I'm also not sure why usermode profiles are opt-out, I think it's much more useful to opt-out from apivector profiles.

Manual tests:

• zfs
• qcow
• lvm

Edit: I also modified the drakplayground to not setup network and restore/destroy VM for vm-0