[#1229] Look for java on the PATH of the caller in upgrade, before it narrows PATH to /bin:/usr/bin (#1230)

Fixes #1229

### Problem

`upgrade` was the only launcher that sourced `lib/_script-util.sh` with
`set-environment-vars` (`PATH=/bin:/usr/bin`) before
`lib/_server-script.sh` looked for java. The `command -v java` lookup
(`_script-util.sh:66`) therefore missed a java that is on the caller's
`PATH` only from another directory. With no `OPENDJ_JAVA_HOME`,
`JAVA_HOME` or `java-home` property to fall back on, `upgrade` exited
with `Please set OPENDJ_JAVA_HOME ...`. `start-ds`, `ldapsearch` and the
other tools started from the same shell found java.

Where `JAVA_HOME` let the lookup succeed, as in the Docker image built
on `eclipse-temurin`, dash still printed `test: -a: unexpected operator`
on every run, because line 67 tested the empty result without quotes.

### Fix

- `upgrade` now sources `_script-util.sh` with `set-java-home-and-args`
first, and only then with `set-environment-vars`. `set_opendj_java_bin`
exports `OPENDJ_JAVA_BIN`, and `_server-script.sh` takes it as it is, in
the first branch of its lookup. So java is resolved from the caller's
environment, as for every other tool, and the rest of the script still
runs with the narrowed `PATH`.
- `_script-util.sh:67` now quotes `TEST_JAVA_PATH`. An empty lookup
result fails the test without a message, and the function goes on to
`JAVA_BIN`, `JAVA_HOME` and, if neither is set, the error message.
- `set_environment_vars` appends `--add-exports`/`--add-opens` and
`--enable-native-access` only where `OPENDJ_JAVA_ARGS` does not hold
them yet, and runs the probe of each only then. `upgrade` now runs the
function with `OPENDJ_JAVA_BIN` known, and `_server-script.sh` runs it
again in the child. Without the guard, the three module flags reached
the upgrade JVM twice, and every run started two more `java --version`
JVMs. The tools that run the function once get the same arguments as
before. On JDK 11, which refuses `--enable-native-access`, the child
still probes that flag, so `upgrade` starts one `java --version` JVM
more than at master there; the flags it passes are the same.

The Windows launchers do not narrow `PATH` and are not changed.

### Test

Three checks in the `Docker test` step of `build.yml`, on the running
container:

- `upgrade -n --force` with `JAVA_HOME` unset must succeed. In the
default image, java is on the `PATH` only from `/opt/java/openjdk/bin`.
- Two passes of `set-environment-vars` in one shell, as `upgrade` and
`_server-script.sh` run it, must leave one `--add-opens` in
`OPENDJ_JAVA_ARGS`. This pins the guard: the JVM takes the doubled flags
without a warning, so nothing else fails without it.
- `ldapsearch --version` with `PATH=/bin:/usr/bin`, so with no java
anywhere, must not print `unexpected operator`.

On alpine the first and the last check pass with or without the fix,
because `/usr/bin/java` is there. The default image is the one that
catches a regression of the lookup. The check of the guard fails without
it in both images.

Local RED/GREEN: the lines of the step were taken from `build.yml` and
run in an `openidentityplatform/opendj:5.2.0` container, whose scripts
are the same as on master, with the scripts of this branch copied in:

| Scripts | Result |
|---|---|
| 5.2.0 (same as master) | fails at the first check: `Please set
OPENDJ_JAVA_HOME ...`, exit 1 |
| `upgrade` fixed only | first check passes, second fails:
`_client-script.sh: 67: test: -a: unexpected operator` |
| this branch | pass |

The check of the guard, cut from `build.yml` and run with `docker exec`
in running 5.2.0 (dash) and 5.2.0-alpine (busybox ash) containers: with
`_script-util.sh` of `upgrade` fixed and no guard it exits 1 in both (2x
`--add-opens`, 4x `--add-exports`), with this branch it exits 0 (1x /
2x). It fails at master as well, which has no guard; there `upgrade`
itself does not double the flags, because its first pass runs without a
java.

The arguments of the upgrade JVM, with a `java` on the `PATH` that logs
its argv and runs the real one, in the 5.2.0 container (dash) and the
5.2.0-alpine container (busybox ash):

| Scripts | `java --version` probes | `--add-exports` / `--add-opens` |
|---|---|---|
| master | 2 | 2 / 1 |
| `upgrade` fixed, no guard | 4 | 4 / 2 |
| this branch | 2 | 2 / 1 |

The master row is from the default image only: on alpine, master finds
`/usr/bin/java` under the narrowed `PATH` and does not run the logging
java. At this branch the upgrade argv is the same as at master, and so
is the argv of `ldapsearch`, `export-ldif` and `status`, in both images.

Both images run JDK 25, which accepts `--enable-native-access`. JDK 11
refuses it, and it is the minimum in the pom and the java of the
`linux/386` alpine image. With the same logging java, over two passes of
`set-environment-vars` run as `upgrade` runs them (its own, master
without `OPENDJ_JAVA_BIN`, then one in a child shell), in
`eclipse-temurin:11-jre` (11.0.32) and `eclipse-temurin:21-jdk`:

| Scripts | probes, JDK 11 | probes, JDK 21 |
|---|---|---|
| master | 2 | 2 |
| `upgrade` fixed, no guard | 4 | 4 |
| this branch | 3 | 2 |

On JDK 11 the child pass probes `--enable-native-access` again, as the
first pass appended nothing. After both passes `OPENDJ_JAVA_ARGS` holds
2x `--add-exports` / 1x `--add-opens` with this branch on both JDKs, as
at master.

Before the guard was added, images 5.2.0 and 5.2.0-alpine with the
scripts of this branch also passed the whole `Docker test` step and the
`Docker test upgrade from a released image` step, with 5.1.2 as the
release. The latter is a real upgrade through `run.sh`, including the
`.upgrade-pending` cases.