container persistence

Objectives:
  1. Avoid file system implementation bias on libcontainer API
  2. Make the caller of the API responsible for storing/persisting the state necessary to re-create
     a container from the underlying cgroups, etc.
  3. Ideally, clarify the notion of ownership in the API to avoid write conflicts due to misunderstanding.
     At a minimum this needs to be clearly documented.

Current situation

Caller passes a file system path on Create. libcontainer stores a "memento" (file) there sufficient to
re-create the Container instance. When this or another caller wants to re-create the container, it
passes the original path on Load() and libcontainer reads the memento and returns a corresponding
Container instance.

Problems

1. The choice of file system based implementation is exposed on the API. It would be hard to switch to
   different implementation without impacting callers.
2. The caller has to manage writeable directories and pass these in, even when persistence isn't needed.
3. The notion of ownership is unclear: the caller of Load could easily use the returned Container
   to interfere with the use of another Container instance.
   
Proposal

Add a method to the Container interface to obtain a "memento" (possibly just an "opaque" array or slice
of bytes) and add a method to the Factory interface to (re-)construct a Container from a memento. The
caller is free to persist the memento to a file if they want to.

The memento includes the Container's id (sufficient to find the cgroup hierarchy), the init pid,
the start time of the init pid, network bridges, and the container configuration. 

The "owner" should be responsible for managing the memento, but the API is happy to dish out mementos
and construct Containers from mementos as requested.

The API provides a way of registering a callback function which is driven when the memento content
changes. The callback is passed the new memento. The callback could, for example, update the
file with the new memento. Only the "owner" should be able to register a callback, so the callback is
a synchronous notification in the owner's process. For simplicity, the callback must not call the API
and if it does, the behaviour is undefined.

Optionally, the Factory could have methods to load either a Container or a read-only view of a Container
from a memento, thus clarifying ownership.