Fixes the "multiple @param documentation sections" doxygen warnings (#6195)

Addresses the "multiple @ param documentation sections" warnings are caused by the interaction of three things:

1. MACRO_EXPANSION = YES with EXPAND_ONLY_PREDEF = NO in Doxyfile.in

2. Versioned API macros in H5version.h like:

\def documentation in APIVersions.dox like:

3. \def H5Tarray_create \api_vers_2{H5Tarray_create,H5Tarray_create1,H5Tarray_create2}

Because Doxygen expands all macros, it sees H5Tarray_create as an alias for H5Tarray_create1. It then associates documentation from both the \def block (for the macro) and the function's own doc block (with \param entries) with the same function — resulting in "multiple @ param documentation sections."

* Update Doxygen version from 1.16.0 to 1.16.1

Use Doxygen 1.16.1 for all platforms. This version includes the latest
bug fixes and improvements while maintaining compatibility with our
documentation format.

* Fix Windows Doxygen installation for version 1.16.1

Handle different Windows binary naming conventions across Doxygen versions:
- 1.16.1 uses: doxygen-VERSION.windows.x64.bin.zip
- 1.16.0 uses: doxygen-VERSION.x64.bin.zip

Try the newer naming convention first, then fall back to the older one
if the download fails. This ensures compatibility across versions.

* Use ssciwr/doxygen-install in setup-doxygen action

Replace direct installation of official Doxygen binaries with
ssciwr/doxygen-install action. This avoids Java documentation parsing
errors that occur with official binaries but not with distribution
builds.

The setup-doxygen action now serves as a thin wrapper around
ssciwr/doxygen-install@f13be16c83 (v1),
using commit hash for security and reproducibility.

* Remove redundant version specification from workflows

The setup-doxygen action already has a default version (1.16.1),
so explicit version specification in workflows is unnecessary.
This follows DRY principles and makes version updates simpler.

java/hdf/hdf5lib/H5.java

@@ -133,7 +133,7 @@ import org.slf4j.LoggerFactory;
  * </tr>
  * <tr>
  * <td>void * <br />
- * (i.e., pointer to `Any')</td>
+ * (i.e., pointer to Any)</td>
  * <td>Special -- see @ref HDFARRAY</td>
  * </tr>
  * </table>
@@ -194,11 +194,11 @@ import org.slf4j.LoggerFactory;
  * @endcode
  *
  * <p>
- * where ``void *'' means that the data may be any valid numeric type, and is a contiguous block of bytes that
+ * where "void *" means that the data may be any valid numeric type, and is a contiguous block of bytes that
  * is the data for a multi-dimensional array. The other parameters describe the dimensions, rank, and datatype
  * of the array ondisk (source) and in memory (destination).
  * <p>
- * For Java, this ``ANY'' is a problem, as the type of data must always be declared. Furthermore,
+ * For Java, this "ANY" is a problem, as the type of data must always be declared. Furthermore,
  * multidimensional arrays are definitely <i>not</i> laid out contiguously in memory. It would be infeasible
  * to declare a separate routine for every combination of number type and dimensionality. For that reason, the
  * @ref HDFARRAY <b>HDFArray</b> class is used to discover the type, shape, and
@@ -206,7 +206,7 @@ import org.slf4j.LoggerFactory;
  * static  C order.
  * <p>
  * The upshot is that any Java array of numbers (either primitive or sub-classes of type <b>Number</b>) can be
- * passed as an ``Object'', and the Java API will translate to and from the appropriate packed array of bytes
+ * passed as an "Object", and the Java API will translate to and from the appropriate packed array of bytes
  * needed by the C library. So the function above would be declared:
  *
  * @code