Execute Gradle in parent context in Windows scripts

[mataha]

Context

Windows script gradlew.bat executes Gradle within its own, batch context. This causes every locally declared variable to be visible to underlying java process, potentially leaking information about used options and classpath.

To mitigate this, we jump to a non-existent label, forcing cmd.exe to stop processing the script, yet run the remaining commands within the current line in parent (most likely command-line when invoking gradlew directly) context. This introduces a harmless side-effect in form of corrupting the current title of the window cmd.exe was invoked in, thus it is reset to the default value.

This provides a few side benefits:

• no more 'Terminate batch job (Y/N)?' prompt
• call and call are used to directly set exit code, resolving Fix for Batch scripts not properly signalling a failure in a pipeline #4784
• both sh and cmd.exe scripts become synchronized in terms of mechanism used to execute JVM as well as environment sanitization

Issue: #10463

Contributor Checklist

• Review Contribution Guidelines.
• Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
• Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
• Provide unit tests (under <subproject>/src/test) to verify logic.
• Update User Guide, DSL Reference, and Javadoc for public-facing changes.
• Ensure that tests pass sanity check: ./gradlew sanityCheck.
• Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet

Before merging the PR, comments starting with

• ❌ ❓must be fixed
• 🤔 💅 should be fixed
• 💭 may be fixed
• 🎉 celebrate happy things

[ljacomet]

Thank you for your contribution!

• Can you explain the added deprecations?
• See below for not needed change

Once these are addressed, someone with bat knowledge will need to take a look at the proposed changes.

[ljacomet]

❌ This file is generated and should not be modified in a PR

[mataha]

Done.

[mataha]

• Can you explain the added deprecations?

Since we're exiting the batch context with (goto) and resetting the exit code afterwards, there's no code to run after that line, which makes exitEnvironmentVar and its getters/setters obsolete.

I've considered removing it altogether - that said, it would break binary compatibility, so I've chosen to deprecate it instead to show that it's not used nor needed anymore; I'm not 100% set on that though. I just felt that exitEnvironmentVar removal should be communicated to the user somehow.