Prepare ground for moving on new API

This series allows to start an init process in a new CT. In this version CT isn't created actually. This will be done in future patches.

I need to get answers on a few questions to continue this work.

1. StartProcess() starts a process inside the container.
If the container isn't started yet, this function will create a process in a new set of namespaces.
If the container is running, a new process will be created in the set of namespaces which belong to the container.
If all processes in the CT have died, this function will create a process in a new set of namespaces ().
If all those statements are true, it looks strange that we don't want to know when a new container is created and when a process is executed in an existing container.

2. How to follow container's state? We return PID-s of processes to users, so we can't call the waitpid() syscall for them. Are we going to monitor cgroup file system events or something like this?

3. Are we going to support containers without pidns? In this case State.Init Pid looks meaningless.

4. Are we going to support "permanent" containers? A "permanent" container is a container which can live without processes. For example the ip utility creates such containers "ip netns add test". In this case /proc/pid/ns/* files should be bind-mounted to somewhere and these links are used for setns().
I think it should. When CT is created, a new process is forked in a new set of namespaces and this process must call execve() immediately. So an user of libcontainer has to create a program which will be executed in a new set of namespaces and call StartInitialization(). For example "nsexec init" will call this method.