A more flexible approach to Tinkerbell Actions

[chrisdoherty4]

Original issue: tinkerbell/tink#136

Summary

These Action Images, ..., are limited by what OSIE can do. In fact, this binding is quite tight and probably by mistake.

Some examples of this:

• BSDs can't really do a "native" installation by running their own software, they have to first create an installer which works under Linux.
• Windows is similar, probably closer to spewing bytes to disk than anything else.
• The OS must install to a filesystem supported by OSIE
• Hardware must be supported by OSIE. Action Images can't bring their own hardware support
• Lots of tools actually have to be "matched pairs": where the CLI utility version is tied to a specific version of the kernel module. For example: wireguard, zfs, iptables, nvidia, among many > others. Incompatibilities can cause simple breakage, instability, or crashes.

Some different ways to work around this might be:

1. support Action Images being light-weight VMs, via something like qemu.
2. allow a workflow to specify its own URL or ID or name for its OSIE workflow base

See the original issue for some additional detail.