Play Framework

fix: make bundled play launcher Windows-aware (release 1.13.58)

PF-171: `play bundle`'s launcher built the runtime classpath with the POSIX
separator and passed POSIX absolute paths for application.path/framework.path.
Under Git Bash on Windows the shell is POSIX but the JVM is native, so java.exe
read the ':'-joined classpath as one nonexistent entry and could not resolve
'/c/Users/...'. The -javaagent kept the framework jar itself loadable, which is
why the failure surfaced as NoClassDefFoundError on Netty and looked like a
packaging bug rather than a separator bug.

bundle-play.sh now detects MSYS/MinGW/Cygwin from `uname -s`, joins the
classpath with ';' there, and routes application.path/framework.path through
`cygpath -w`. The .classpath entries and -javaagent stay relative and untouched
— they resolve against the launcher's own `cd "$SCRIPT_DIR"`, which a Git
Bash-spawned native process inherits already translated. No-op on macOS/Linux.

Also gates the gradle-plugin's own suite in CI. It lives in a separate Gradle
build, so no ant sourceset reached it and `ant test` passed while the plugin
shipped untested — which is how a defect in a plugin *resource* reached a user.
A new `gradle-plugin-test` ant target shells out to :gradle-plugin:test and runs
at the end of `ant test`, so the existing CI step gates it on every leg;
gradlew.bat is selected on Windows. Failure artifacts now include the plugin's
test reports.

Adds BundleLauncherTest, which drives the real launcher against stubbed
uname/cygpath/java and asserts the argv handed to the JVM on both platforms.
Verified to fail against the pre-fix script.

Drops the stale Eclipse gradle-plugin/bin/ tree from the distribution zip; it
was shipping a pre-fix copy of the launcher into every release.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>