Fix CodeQL note-severity alerts: uncaught NumberFormatException in the examples

[vharseko]

Sixth and last batch of note-severity code scanning fixes for the java/uncaught-number-format-exception rule (after #814, #817, #823, #826 and #829): the 32 alerts left in the example applications, which #829 deliberately did not touch.

Every one of them is the port the example connects to, parsed straight from the command line:

final int port = Integer.parseInt(args[1]);

Running an example with a non numeric port therefore ended with a NumberFormatException stack trace, while every other invalid argument of the same examples is reported properly (Unknown scope: …, usage message, System.exit(CLIENT_SIDE_PARAM_ERROR)).

What changed

• opendj-ldap-sdk-examples (28 alerts, 26 files) — a new package private ExampleUtils.parsePort() reports an invalid port on standard error and exits with CLIENT_SIDE_PARAM_ERROR, which is exactly what these examples already do for an unknown scope. Each call site becomes final int port = parsePort(args[1]); plus one static import.
• opendj-embedded-server-examples (4 alerts, 2 files) — SetupServer and ConfigureServer keep a private parsePort() of their own: the module is separate and only has two affected files, so duplicating a ten line helper is preferable to sharing a class across artifacts of the same package. The default ports (1500, 4500, 1600) and the surrounding conditionals are unchanged.

Documentation

The argument parsing of these examples sits before the // --- JCite --- markers, so the regions included into the documentation are untouched — the samples read exactly as before where it matters.

The static import blocks of the modified files are sorted and separated from the regular imports.

Testing

The example modules have no tests; both opendj-ldap-sdk-examples and opendj-embedded-server-examples compile cleanly, and no Integer.parseInt(args…) remains in either module.