Start shims after creating containers

[sameo]

Right now the virtcontainers core code explictly starts shims as soon as possible, regardless of the shim implementation being able to handle non existing containers or not.

This PR reorders that sequence and guarantees that shims will not be started before their corresponding container process is not started.

Now we have:

• container.go createContainer basically only allocate a new container structure and asks the agent to create it on the guest.
• It is up to each agent implementation to decide if there's a need to associate a shim to a container's process or not. i.e. the agent is now responsible for launching the shims.
• pod.go startShims is now createContainers() and calls into createContainer() for each configured container.

[sameo]

@sboeuf This is an attempt at reorganizing the code for having the shims only started after the container is created on the guest, in order to avoid the SIGUSR1 synchronization.

[sameo]

This should pass unit testing now, at least :-/

[sameo]

simple integration tests are failing, will fix those today as I can reproduce on my local env.

[sameo]

Basic integration tests now work with kata and CC with that PR. I'd say it's ready for review @sboeuf @jodh-intel

[sboeuf]

@sameo cool, I'll review this tomorrow.

[sboeuf]

LGTM Let's wait for the last patch fixing the docker exec command and we'll be good to merge this. As a follow up, I'll raise a PR implementing what's described here

[sameo]

coverall says we're at 63% with that PR...merging.