"bazel clean": prevent creation of command.log

Open files cannot be deleted on Windows, thus
`bazel clean --expunge` fails when it attemps to
delete the `command.log` that stdout/stderr is
tee'd into, and so does BlazeCommandDispatcher
when it attemps to delete the `command.log` just
before dispatching to the command implementation
(not just `clean` but any command).

This change:
- closes `command.log` before we attempt to
  delete it
- marks CleanCommand (through the Command
  annotation) as one that should not write to the
  command.log, thus we don't create a new instance
  of the file

This change allows `bazel clean --expunge` to
delete everything in the output base, with the
exception of `jvm.log`. Unfortunately that file is
opened by the C++ bazel client process, so we have
to close it there prior to sending the clean to
the bazel server.

See https://github.com/bazelbuild/bazel/issues/1586

--
MOS_MIGRATED_REVID=137278553
diff --git a/src/main/java/com/google/devtools/build/lib/runtime/Command.java b/src/main/java/com/google/devtools/build/lib/runtime/Command.java
index c415f0a..4db5627 100644
--- a/src/main/java/com/google/devtools/build/lib/runtime/Command.java
+++ b/src/main/java/com/google/devtools/build/lib/runtime/Command.java
@@ -15,7 +15,6 @@
 
 import com.google.devtools.common.options.Option;
 import com.google.devtools.common.options.OptionsBase;
-
 import java.lang.annotation.ElementType;
 import java.lang.annotation.Retention;
 import java.lang.annotation.RetentionPolicy;
@@ -89,6 +88,13 @@
   boolean binaryStdErr() default false;
 
   /**
+   * Returns true if this command may want to write to the command.log.
+   *
+   * <p>The clean command would typically set this to false so it can delete the command.log.
+   */
+  boolean writeCommandLog() default true;
+
+  /**
    * The help message for this command.  If the value starts with "resource:",
    * the remainder is interpreted as the name of a text file resource (in the
    * .jar file that provides the Command implementation class).