Mounts are the main interaction mechansim in containerD. Container systems of

the past typically end up having several disparate components independently

perform mounts, resulting in complex lifecycle management and buggy behavior

when coordinating large mount stacks.

In containerD, we intend to keep mount syscalls isolated to the container

runtime component, opting to have various components produce a serialized

representation of the mount. This ensures that the mounts are performed as a

unit and unmounted as a unit.

From an architecture perspective, components produce mounts and runtime

executors consume them.

More imaginitive use cases include the ability to virtualize a series of mounts

from various components without ever having to create a runtime. This will aid

in testing and implementation of satellite components.

The `Mount` type follows the structure of the historic mount syscall:

| Field | Type | Description |

|-------|----|-------------|

| Type | `string` | Specific type of the mount, typically operating system specific |

| Target | `string` | Intended filesystem path for the mount destination. |

| Source | `string` | The object which originates the mount, typically a device or another filesystem path. |

| Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. |

We may want to further parameterize this to support mounts with various

helpers, such as `mount.fuse`, but this is out of scope, for now.