Play Framework

feat: Play 1.13.x shell `play` wrapper + plugin updates (PF-90)

Replaces the Python `play` CLI with a shell script that wraps Gradle.
Functionally identical from a user's view — `play start --%prod
--http.port=9000 -Xms512m -Xmx2g -XX:+UseZGC ...` works the same as
in 1.12, with the wrapper translating into Gradle's wire format
(properties + plugin task) under the hood.

Wrapper translations (in /opt/play1/play and play.bat):
  --%<id>             → -PplayId=<id>
  --http.port=X       → -PhttpPort=X            (camelCase plugin prop)
  --https.port=X      → -PhttpsPort=X
  -X*, -D*, -XX:*,    → accumulated into a single
  -Xlog:*, -javaagent:   -PjvmArgs="..." property
  -agentlib:*
  dist                → playBundle              (1.12 `play dist` semantics
                                                  = 1.13 playBundle output)
  --foo=bar / --foo   → -Pfoo=bar / -Pfoo       (generic property pass-through)

Plugin (Play1Plugin.kt):
  - registerPlayJvmTask reads -PjvmArgs and forwards as discrete jvmArgs
    to the JavaExec tasks (covers playRun, playTest, playPrecompile,
    playEvolutions).
  - PlayStartTask + PlayRestartTask: new extraJvmArgs Property<String>;
    task action splits whitespace and passes through to spawnPlay.
  - spawnPlay accepts extraJvmArgs: List<String>, inserted before
    -classpath so they follow `java`'s last-wins precedence.
  - Plus accumulated session work: -Ppid-file=<name> support for
    Start/Stop/Restart/Pid/Out tasks, --include-modules for playJavadoc.

Old Python CLI preserved as play.bak / play.bat.bak so historical
references (e.g. in jclaw.sh comments, in old tutorials) keep their
backing artifact during the 1.12 → 1.13 migration window.

End-user perspective: typing `play start ...` doesn't change between
1.12 and 1.13. The Gradle property names (-PplayId, -PjvmArgs,
-PhttpPort, -Ppid-file) are wire protocol between wrapper and plugin,
not part of the user-facing interface.

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