Support Gradle `gradle.properties` settings for all tasks

### Description

* The gradle build command uses the project JDK specified in `gradle.properties`, e.g.
```
## Java config ################
#
org.gradle.java.home = /prod/lib/java/jdk/v01.08
```

* Our Java 1.8 is required
* Any of the gradle tasks will honour the main project's `org.gradle.java.home` setting
* Provided there is nothing set in `GRADLE_USER_HOME`
```
$ ./gradlew clean
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

> Configure project :

==== 4AMS project: ============
O/S name: Linux
Gradle version: 7.2
Groovy version: 3.0.8
Java version: 1.8.0_312-b07 (vendor: Azul Systems, Inc.)
JDK source: 1.8
JDK target: 1.8

trustURLCodebase => null.

---- 2022-03_Mar-25 23:06 ----

> Configure project :FourAmsWsPo
. . .
```
* We are able to run Netbeans with Java 17, and reap the benefits of the most recent platform for our tooling
* Netbeans should be loading/initialising the "`Project Properties`" panel from the Gradle settings and properties in the project's model
* Notably: **`org.gradle.java.home`**
* Gradle has done the right thing, Netbeans just doesn't seem to check.

### Use case/motivation

* Want a Netbeans Gradle build to perform the same as a command line Gradle build
* Given that `gradle` and `gradlew` use the `org.gradle.java.home` property
* It seems that Netbeans is ignoring or overriding the default Gradle processing
* Currently the ONLY way to ensure a sub-project build is manually and separately change the project properties setting in the GUI
* 
* Everytime a subproject is reopened
* The other aspect involved is that once the build platform is changed for a sub-project Netbeans doesn't persit it.
* See related Issues -- We found that these items are stashed in a cache directory
* Temporary areas are not added to Git
* The setting doesn't seem to 'stick' after a subproject was closed (not that a cache should "stick", of course)
* We feel that the location of this setting is not appropriate. It ought to be in a project build config file like a `gradle.properties` or one of the `.gradle` files.

### Related issues

* We have discovered that the main project and sub-project platform setting is maintained in
* A Gradle cahce area: `.gradle/nb-cache/`
* But instead of using (sub-)project names the settings are named with random integers for example:
```
$ ll .gradle/nb-cache/
total 64
CaaServices-585101997/
CaaServlet-1782244016/
FAMS-470-1013227199/
```
* If the settings were just directory names matching sub-project names they might be copied to a "`settings/`" folder in our porject as a workaround.
* Unfortunately we can't predict the random number used (as show).
* Nor do we thing it should be done that way in the first place (_in the collected opinion_)

### Are you willing to submit a PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow the Apache Software Foundation's [Code of Conduct](https://www.apache.org/foundation/policies/conduct.html)

Start by comparing how the command-line Gradle build reads gradle.properties, especially org.gradle.java.home, with how NetBeans initializes the Project Properties panel for Gradle projects. Inspect the .gradle/nb-cache/ behavior described in the issue and verify that main and sub-project settings are loaded and persist without manual GUI changes.

Written by the indexing model from the issue text.