fix: replace eval-based start command with shell-free javaexec launcher (#1301)

[stokpop]

Problem

The start command used eval "exec java $JAVA_OPTS ..." to launch the JVM.
eval reinterprets its argument as shell code, which made it fundamentally
difficult to preserve JAVA_OPTS values exactly as specified:

• Backslashes were consumed as escape characters (C:\path → C:path)
• Quotes were stripped, so space-containing values split into multiple
  JVM arguments (-Dfoo="bar baz" → -Dfoo=bar + baz)
• Glob characters in unquoted values expanded (*/7 → filenames)
• Pipe and semicolon characters were interpreted as shell operators

Each issue required a new escaping workaround; combinations of edge cases
kept producing regressions. The root cause is that eval is the wrong tool
for passing an arbitrary string as JVM arguments.

Note: this PR replaces #1303 (which can be closed if this is merged, or revived from draft if this PR is not to be merged).

Solution

1. javaexec launcher (src/java/javaexec/)

A compiled Go binary invoked as exec $DEPS_DIR/<idx>/bin/javaexec "$JAVA_HOME/bin/java" <args>.
It tokenizes $JAVA_OPTS using POSIX word-splitting and quote-removal rules,
but performs no further processing: $(...), ${...}, backtick
substitutions, and shell metacharacters (&, |, ;, >) are all passed
literally to the JVM. Nested $(...) and ${...} forms with spaces inside
are kept as one token.

2. Pure-bash _expand_env_vars in profile.d/00_java_opts.sh

Expands $VAR / ${VAR} references using only bash builtins — never
re-interprets quotes, backslashes, or metacharacters. The single known trusted
substitution $(nproc) is resolved explicitly. \$VAR passes a literal
$VAR to the JVM (Ruby buildpack parity). A WARNING is emitted to stderr
(showing only the offending token) when $(...) or a backtick appears in
user JAVA_OPTS.

Other fixes included

• memory_calculator.go, jvmkill.go: replace hardcoded /home/vcap/deps/
  with $DEPS_DIR so installs work on non-default CF stacks.

Test coverage

• Tokenizer unit tests: quoting, metacharacters, $(...) grouping,
  ${...} extended forms, backtick, nested parens, full manifest scenario.
• End-to-end runStartCommand tests: exact v5.x regression: JAVA_OPTS handling broken (pipes/newlines in 5.0.2, quoting in 5.0.3) #1301 reproducer (cron + quoted
  spaces), pipe, metacharacters, command substitution not executed (marker
  file guard), \$VAR escape, warning token extraction, POSIX word-split
  documentation.
• Integration: runStartCommand smoke test verifying javaexec fires for
  Spring Boot, Java Main, Play, Tomcat containers.

Closes #1301

[ramonskie]

Medium: bin/javaexec is required but not built for git/source buildpack usage.

installJavaexecLauncher() now reads <buildpackDir>/bin/javaexec, which works for packaged buildpacks because scripts/build.sh creates it. But direct git/source usage only builds the finalize binary via bin/finalize; it does not build src/java/javaexec/cli, and bin/javaexec is not checked in.

This means source buildpack usage such as WithBuildpacks("https://github.com/cloudfoundry/java-buildpack.git") can fail during finalize with “javaexec launcher binary not found”.

Suggested fix: update the source/git wrapper to build javaexec too, or make installJavaexecLauncher() use a generated/temp javaexec path when running from source.

[ramonskie]

I did a deeper pass on the javaexec integration. The launcher approach itself looks like the strongest option for the problem this PR is solving: bash arrays, JAVA_TOOL_OPTIONS/JDK_JAVA_OPTIONS, generated shell wrappers, or per-container fixes either reintroduce a parser/eval problem, do not preserve current JAVA_OPTS semantics/order reliably, or only address part of the eval surface.

The issue I think still needs addressing is lifecycle/packaging integration:

• installJavaexecLauncher() runs unconditionally during finalize.
• It requires <buildpackDir>/bin/javaexec to exist.
• Packaged buildpacks get that from scripts/build.sh, but source/git usage via bin/finalize only builds src/java/finalize/cli into a temp dir.
• Because bin/javaexec is ignored/not checked in, source/git usage can fail staging for any app type, including apps whose final start command does not use javaexec, since finalize aborts before release completes.

WriteProfileD itself does not look directly broken. CreateJavaOptsAssemblyScript() still writes profile.d/00_java_opts.sh before the launcher install step. The failure mode is that profile.d may be written successfully, then finalize aborts while copying the missing launcher.

A safer fix would be to make the source/git wrapper build src/java/javaexec/cli into the same temp directory as the finalize binary, then pass that explicit binary path into finalize, for example via an env var. installJavaexecLauncher() could prefer that override and fall back to <buildpackDir>/bin/javaexec for packaged buildpacks. That keeps packaged behavior unchanged, avoids mutating the source checkout during staging, and preserves the good part of this PR: shell-free handling of user-provided JAVA_OPTS at the final JVM exec.