Fix Docker Containerizer PATH on Windows so Docker is usable

When fixing MESOS-6816 (Allows frameworks to overwrite system environment variables) for Windows, we reconciled the Windows executor behave with that of Linux. Previously, Windows would explicitly query for the system environment, and set that for the executor. However, this is incorrect from Mesos's standpoint, which explicitly constructs a "pristine" environment for the executor. On Linux, this is not really a problem, as the os::host_default_path() tends to always contain the binaries users may run (including docker), since the paradigm on Linux is that packages install their binary to e.g. /usr/local/bin or /usr/bin. However, on Windows, "packages" / software do not install binaries to the default system PATH. Instead, the system PATH is modified to include the software's directory.

The unfortunate case is that this true for Docker. When Docker is installed on Windows, docker.exe does not exist in the default path, instead some folder under Program Files is added to the system PATH environment (and this folder changes based on client vs server installs; that is, it is inconsistent). This means that the "correct" behavior of the execuctor (specifically when using the Docker containerizer) pretty much breaks on Windows, as the containerizer is unusable (it cannot find docker.exe) without the user manually finding the PATH and passing it on the command-line (or in the task info).

More unfortunately, users of Mesos on Windows are already depending on this buggy "feature" and so currently 1.5.0 will break all deployments of Mesos on Windows using containers. Hence this is a blocking bug.

Joseph Wu and I came to the conclusion that the most unobtrusive fix is to append the folder which contains docker.exe (found by running os::which(docker) in the context of the agent, which still has the system environment) to the PATH environment that will be used for the executor. So we'll maintain the "pristine" environment, but also have Docker in the path (if it exists). This will not break if someone passes an absolute path to the Docker executable, or if someone manually sets the PATH environment.

There is the edge case that Docker was installed and then subsequently renamed. However, we're not going to handle this, as we're trying to make a reasonable PATH variable, which is os::host_default_path() + "typical Docker installation". If they rename docker.exe, they're on their own to pass it or pass the environment.