The new tests of deeply nested constants (constants where memoization is needed to avoid exponential blowup) is causing test.py runs on Windows with dart2js batch mode to fail because the dart2js batch process is left alive or zombie after test.py exits.

This causes swarming tasks to fail because their file system can't be cleaned up.

This is quite reproducible, and happens every time on the Windows bots. We need to find out what is happening where dart:io Process.kill is not actually terminating its process, in this case.

@rmacnak-google @whesse @vsmenon

I propose adding logging in the batch runners terminate() code, which will track the processes that are created and those that are terminated, and verify that they are really gone, on Windows.

For now, I will skip these new tests on Windows dart2js, because they mean that no windows test results are generated at all, since the runner crashes.

Link to log of this failure:
https://ci.chromium.org/p/dart/builders/ci.sandbox/dart2js-strong-win-x64-chrome/4574

example log:
Enumerating processes:

• pid 472; Handles: 108; Exe: C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\dart.exe; Cmd: "C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\dart" "C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\snapshots\dart2js.dart.snapshot" "--libraries-spec=C:\b\s\w\ir\out\ReleaseX64\dart-sdk\lib\libraries.json" --batch
  Terminating 1 processes:
• 472 killed
  Failed to delete C:\b\s\w\ir. The following files remain:
• \?\C:\b\s\w\ir
• \?\C:\b\s\w\ir\out
• \?\C:\b\s\w\ir\out\ReleaseX64
• \?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk
• \?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin
• \?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\dart.exe
  7200 2019-07-25 09:11:09.806 E: rmtree(u'C:\b\s\w\ir') failed: [Error 5] Access is denied: u'\\?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\dart.exe'
  *** Swarming tried multiple times to delete the run directory and failed ***
  *** Hard failing the task ***