[#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.

This is one of the points I wasn't sure about - I'm not convinced that the existing behaviour that vcore exhibits is the best option, but I don't know the history behind the choice.

What I've got right now, between Vcloud::Launcher::Preamble and this handling here is that the existing behaviour is preserved, but I think with some small changes, additional use cases could be handled.

I've currently got some pending tests around what Vcloud::Launcher::Preamble considers valid that I was intending to change following review.

Right now the specs do something that's close to what you suggest (and I'm happy to make it more explicit):

From `bundle exec rspec ./spec/vcloud/launcher/vm_orchestrator_spec.rb -f doc`:
```
  when generating a preamble
    without supplying a template path
      behaves like it silently swallows errors
[...]
    without supplying template vars hash
      behaves like it silently swallows errors
[...]
```

I was thinking that a missing or empty `vars` should be considered acceptable by Vcloud::Launcher::Preamble and that any template should be returned as-is, rather than returning an empty string. With current or this proposed behaviour, a new VM is likely to be broken, but at least one gets the actual script on the box complete with errors, rather than a missing preamble.

Secondly, and more helpfully, permitting an empty `vars` (and by implication, a preamble that doesn't require interpolation) it opens up the ability to post-process an already workable preamble script before handling it off to the VM. To achieve this currently, a dummy `vars` is required in combination with a post processor.

Once this code was reviewed and hopefully merged I was planning on taking the next step and exposing a way of getting at the preamble script via vcloud-launcher or a supporting tool to aid debugging, rather than only being able to get at the preamble on a minimally-functional VM. This would make what ends up on the box less important, as Vcloud::Launcher::Preamble's `.interpolated_preamble` and '.generate` methods would return the interpolated file and (potentially) post-processed file for inspection on the command line.

Further guidance welcome!