Tidy up the semantics of Command.arguments[0]

Bazel Buildfarm, Buildgrid and Buildbarn all perform resolution relative
to the working directory of an action; not the input root directory.
Instead of requiring that all implementations are updated, we should
consider just altering the spec.

Performing resolution relative to the input root directory can also be
very tricky, as it means that argv[0] as visible to the calling process
must also be rewritten. Applications may get confused otherwise. For
example, consider the case where the working directory is "foo" and
argv[0] is "bar/baz". In that case argv[0] as visible to the calling
process must become "../bar/baz" or be made absolute. Making it absolute
is inconsistent with what Bazel does right now. Attempting to keep it
relative can be complex when symbolic links are involved.

Furthermore, the specification doesn't mention what kind of path
separators are used for argv[0]. The only reasonable solution here is to
use path separators that are native to the host, as successive arguments
also need to be provided in that form.

build/bazel/remote/execution/v2/remote_execution.proto

@@ -539,7 +539,10 @@ message Command {
 
   // The arguments to the command. The first argument must be the path to the
   // executable, which must be either a relative path, in which case it is
-  // evaluated with respect to the input root, or an absolute path.
+  // evaluated with respect to the working directory, or an absolute path. Path
+  // separators native to the operating system running on the worker are used.
+  // Paths that do not contain contain any path separators must be resolved
+  // using the operating system's equivalent of the PATH environment variable.
   repeated string arguments = 1;
 
   // The environment variables to set when running the program. The worker may