Windows: add --incompatible_windows_escape_jvm_flags

[laszlocsomor]

Add --incompatible_windows_escape_jvm_flags flag
(default: false). This flag has no effect on
platforms other than Windows.

This flag affects how Bazel builds the launcher of
java_binary and java_test targets. (The launcher
is the .exe file that sets up the environment for
the Java program and launches the JVM.)

In particular, the flag controls whether or not
Bazel will Bash-tokenize the jvm_flags that were
declared in the BUILD file, and whether or not
these jvm_flags are escaped by the launcher when
it invokes the JVM.

When the flag is enabled:

• Bazel will Bash-tokenize java_binary.jvm_flags
  and java_test.jvm_flags (as documented by the
  Build Encyclopedia) before embedding them into
  the launcher. The build fails if an entry cannot
  be Bash-tokenized, e.g. if it has unterminated
  quotes.

• The launcher will properly escape these flags
  when it runs the JVM as a subprocess (using
  launcher_util::WindowsEscapeArg2).

• Result: the jvm_flags declared in the BUILD file
  will arrive to the Java program as intended.
  However, due to the extra Bash-tokenization
  step, some ill-formed flags are no longer
  accepted, e.g. jvm_flags=["-Dfoo='a"] now
  results in a build error.

When the flag is disabled:

• Bazel does not Bash-tokenize the jvm_flags
  before embedding them in the launcher. This
  preserves quoting meant to be stripped away, and
  it also means Bazel won't check whether the
  argument is properly quoted.

• The launcher escapes the flags with a Bash-like
  escaping logic (launcher_util::WindowsEscapeArg)
  which cannot properly quote and escape
  everything.

• Result: the jvm_flags declared in the BUILD file
  might get messed up as they are passed to the
  JVM, or the launcher may not even be able to run
  the JVM. However, due to the lack of
  Bash-tokenization, Bazel propagates some flags
  to the Java binary that it would no longer
  accept if the new
  --incompatible_windows_escape_jvm_flags were
  enabled, e.g. jvm_flags=["'a"] is fine.

Incompatible flag: #7486

Related: #7072

RELNOTES[NEW]: Added --incompatible_windows_escape_jvm_flags flag: enables correct java_binary.jvm_flags and java_test.jvm_flags tokenization and escaping on Windows. (No-op on other platforms.)

Change-Id: I531cc63cdfeccbe4b6d48876cb82870c1726a723

[lfpino]

/CC @cushon

[lfpino]

shift after fetching $1

[laszlocsomor]

Why?

[laszlocsomor]

@lfpino : PTAL

[lfpino]

Much better!

[lfpino]

nit: Unless it's necessary, use concrete values for pkg, it removes one layer of indirection when looking at the lines of code using it.

[laszlocsomor]

I'd like to keep it like this. This generates a unique package name for every test.

In case the test cleanup logic were flawed (which would certainly be a bug that should be fixed) such that it didn't fully clean up after tests, we'd still run every test with its own package, reducing the chance that tests overwrite each others files.

[laszlocsomor]

All done.