[#66849308] Move preamble handling from vcloud core

This is a pre-emptive PR, for review and feedback, not necessarily for immediate merge - comments are more than welcome!

@annashipman As discussed, this PR moves machine preamble template processing from vcloud-core up to vcloud-launcher.

I'll open a separate PR shortly to update vcloud-core to follow this change.

I've added a new Vcloud::Launcher::Preamble class based on the preamble handling in Vcloud::Core::Vm. I've also carried over specs from vm_spec.rb, and adjusted to suit.

The main change of note that I've made is that rather than silently returning empty string if `bootstrap[:vars]` was missing or empty or if `bootstrap[:script_path]` was missing, I now raise exceptions from Vcloud::Launcher::Preamble's constructor. Those exceptions are currently being caught in the updated Vcloud::Launcher::VmOrchestrator and an empty string returned there instead.
I'm not convinced that returning an empty string is the best option, but it does at least allow provisioning to continue, for better or worse.
I think permitting an empty `bootstrap[:vars]` would allow for post-processing a preamble script without the need to first interpolate it (or include dummy `bootstrap[:vars]` for a no-op interpolation).
I'm looking to add the ability to dump out the preamble script, in both its interpolated and post-processed forms in a future change.

I've added additional `context` and `describe` blocks in the specs I've touched, where it didn't involve substantial changes. `spec -f doc` now reads better IMHO and this has allowed for grouping of test data.

I've added a number of smaller methods and correspondingly focused specs. Of note:

* Vcloud::Launcher::Preamble.load_file is there to allow for easy stubbing to permit test preamble templates to be fed in.
* Vcloud::Launcher:: VmOrchestrator.generate_preamble handles the aforementioned exception handling, but this is a private method, but one that I think warrants testing, hence the use of `subject.send(:generate_preamble)` in the specs

In writing this PR, I realised that I've not yet moved the example preamble files from vcloud-core to vcloud-launcher - I'll address that shortly.
The preamble files that were used in the specs are no longer used - I'm now testing individual behaviour in individal specs. Comments/improvements on the arrangement of data like this welcome.

I'm not sure I understand the reason for having both the `output` and `generate` methods.