Add VOD deployment job to GitHub workflows

[gbryant-arm]

Our CI doesn't include any tests for the freestanding execution engine (FEE), nor any deployments of relatively complex examples.
In this PR we add a job to GitHub workflows that deploys the video object detection example as a standalone binary, in wasmtime, in the FEE and end-to-end.

The changes add about 5min to the linux job (need to build Veracruz-Linux in addition to running the tests) and the new vod-full-deployment job takes about 4min and is executed after linux. This doesn't affect the total execution time since the icecap job takes more than 30min, which is more than linux and vod-full-deployment combined.

Some ideas to optimise this workflow further (won't be implemented in this PR):

• Build VOD (native and WASM binaries) in parallel to other jobs then share binaries with deployment job
  • Pro: Saves ~1min
  • Con: Adds another concurrent job to the workflow
• Add deployment steps to Veracruz build jobs as opposed to having a separate job for deployment
  • Pro: Saves ~2min (container and artifact sharing overhead)
  • Con: Need to rerun the entire job if deployment fails

[gbryant-arm]

Switching to "ready for review" just to trigger the CI and see what happens

[gbryant-arm]

RFR

[egrimley-arm]

Someone who wants to test the CI on their own machine has to copy-paste quite a lot of shell code from main.yml into a terminal. I wonder if it would be better to move the shell code into a script that one could more easily run manually.

Arguably that's a new feature that's distinct from what you're adding here so could be a separate PR, though. And there are various ways one could do it: for example, a single script that runs a different CI job depending on the argument supplied to it?

[gbryant-arm]

@egrimley-arm The way things are implemented, the VOD readme is parsed by the CI script while still being palatable to someone who doesn't care about the CI and just wants to build and run VOD. Finding the right balance between sharing code in the README and having CI-specific code is hard to find, and I reckon the balance we've reached here is not bad.
Moving CI code to a separate script is possible but would intricate things further.
Out of curiosity, why and how would we run the CI outside of github?

[egrimley-arm]

Out of curiosity, why and how would we run the CI outside of github?

I tend to do that when investigating why CI failed, and I also like to run an abbreviated version of the CI tests, rather than follow entirely separate instructions, to check whether a change I've made breaks anything.