…es (#1477)

We forgot to increment a variable, and we didn't handle all the
primitive types.

We generalize the method so it is useful for parsing either method
argument types or generic type arguments. (The latter required handling
wildcards.) Also factor out some common logic, and make the method
public so it can be used from other projects.

Creates ECJJava15IRTest similar to ECJJava17IRTest in order to test
classes using javaonepointfive package.

To stay up to date

According to [Gradle's
documentation](https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:usage:parallel),
"Configuration cache storing and loading are done sequentially by
default. Parallel storing and loading provide better performance,
however not all builds are compatible with it."  Our build appears to be
compatible, so let's turn this feature on.

That being said, I haven't actually noticed a significant change in
build times.  This feature may affect WALA more in theory than in
practice.

Guava and Error Prone to latest, and use JDK 24 to compile code. (We
can't test WALA on JDK 24 under Gradle supports running on JDK 24.)

…n method name (#1485)

Cleaned up `ECJJava15IRTest.java` by refactoring the tests to be
parameterized to not rely on method name for running the tests. Also
removed the `getTestName` from `IRTests` so the tests do not rely on
that method to get the name of the test it should run. With this we pass
in the name and tests can now be parameterized as well instead of
relying on naming tests differently

---------

Co-authored-by: Manu Sridharan <msridhar@gmail.com>

Gradle 8.14 allows dependency configurations to be "realized only when
necessary."  "This change can lead to reduced configuration time and
lower memory usage in some builds."

Fixes #1491 

As usual, we verify existing tests don't crash on JDK 24 bytecodes, but
we haven't added or tested support for any new features.

We update to Gradle 8.14 RC1 as that version supports running on JDK 24.
We also shift to using Zulu JDK builds wherever possible. Temurin has
enabled JEP 493 for their JDK 24 builds (see
adoptium/temurin-build#4035) which means they
are distributed without `.jmod` files. This breaks WALA's strategy for
loading Java standard library classes from the running VM if no other
location is specified. We need to update [the
wiki](https://github.com/wala/WALA/wiki/Analysis-Scope) to document this
new requirement for JDK 24+ JVMs.

To stay up to date

Previously several parameterized tests used `List`s of items without
custom `toString` methods.  Including these in test names led to
generated test names like `java17IRTestName=CatchMultipleExceptionTypes,
ca=[com.ibm.wala.cast.java.test.ECJJava17IRTest$3@6e576b5a]`, where the
`6e576b5a` part varied randomly from one run to the next.  That
nondeterminism, in turn, led to misleading claims of test churn in test
reports.  For example, [this
report](#1495 (comment))
states that "this pull request removes 118 and adds 118 tests."  No
tests were actually removed, though: 118 tests simply changed the hex
digits in their names.

Now we customize the name template for some parameterized tests to omit
items with nondeterministic `toString` results.  This change should give
us test reports that more truthfully reflect the real amount of test
churn, or lack thereof.

JUnit 5's `assertEquals` method should be called with the _expected_
value _first_ and the _actual_ value _second_.