Volume reconciliation loop

Implements a reconciliation loop that tears down volumes that are no longer in use by any pod.

The set of valid volumes are determined by iterating through the list of manifests. The set of active, or mounted, volumes are determined by traversing the root working directory path for any existing volumes. These maps are compared, and if an active volume does not have a match, it is unmounted and removed.

This allows a kubelet to properly remove mounted volumes and clean up after itself in the event of a crash/restart.
@erictune Is there an existing work queue for these types of operations? Could it be integrated into the PodWorker? As it stands the currently supported volumes call for just an rm -rf on TearDown() but you're right, we don't want this to significantly block the kubelet for large numbers of volumes that require complicated procedures. This optimization could be a separate PR and should definitely not be ignored, but for now I want to focus on getting a proper volume clean-up procedure as there currently isn't any.

@smarterclayton Volumes are uniquely identified by podID and volume name. In the situation you mentioned, provided the manifest specifies the same ID and volume name, if we run TearDown() asynchronously, there may be an unlikely race condition. When the new pod is created again after removal, if SetUp() is executed before TearDown() finishes, the kubelet will build the volume, but TearDown() will remove it while the pod is still running. This seems like a pretty unlikely scenario to begin with, having a user specifically create, remove, then create the same exact pod, *and* have that pod be scheduled to the same kubelet it was previously on, starting before the previous cleanup has ended. If it's something we can't ignore, one solution off the top of my head that doesn't block is to have the reconciliation loop also repair volumes if they are missing, but I also don't know what happens if a bind point doesn't exist or is removed from beneath Docker after the container is already running, or if we can add binds to a running container.