Initial version of libcontainer API.

Docker-DCO-1.1-Signed-off-by: Victor Marmol <vmarmol@google.com> (github: vmarmol)

This is an initial proposal of what a libcontainer API would look like. You can see it is in no way implemented :) This is primarily for discussion on the API, we can merge this and start working on the individual pieces one at a time.

The proposed API borrows heavily from lmctfy and libct with some changes to improve on those. Key aspects are:
- Container names as hierarchical path
- Separating Creating a container from Getting a container (the latter gets a reference to a running container)
- Containers as objects we can perform action on.

Any and all comments are welcomed :) I think the documentation on these may be a little lighter than I'd like. I can add more as it is requested.
Some of this is unclear right now since we need to have a wider discussion around what is in the ContainerSpec. I added some clarification in the docs. I also think it is okay to not be sure right now :) we probably don't have to nail everything down immediately (that review will take forever) rather as a series of smaller discussion over PRs.

I'll also answered your question below:
- I think we should treat namespaces in a hierarchy, as in all namespaces of a subcontainer are "within" the parent's namespace (for namespaces that nest). I find that this is an easier abstraction to give to users and does not significantly reduce what you can do. It becomes very hard to reason about nested namespaces otherwise.
- Yes (at least I think it should be) WDYT?
- Given mount namespaces, this should be true no? I guess it depends a lot on the answer to the two above.
- I'm honestly not sure (not familiar enough) it seems to be that it is our of scope for us (what filesystem you use), but maybe that is completely wrong.
- I added a bit to Destroy() (it is recursive). You can't delete a container with children (or processes) so both must be destroyed when the parent is.
- Parent must be created before the child (although this should provide the primitives to do what you described)
- The root container is just like any other container for the most part. You can see its Spec(), Stats(), Processes(), Threads(), Run() things inside. Things you can't do is Update(), Pause()/Unpause(), and Destroy().
- Since container names are relative (or absolute), we will perform the operations relative (or absolute) to what is specified. In the case that you are within namespaces, you appear to be at ROOT yourself (minus cgroups, but I am of the mind that we should abstract that away in those cases).