Gradle implementation of Project (re)load API

[sdedic]

Gradle implementation, based on improvements in #7646 implementing SPI introduced in #7651.

The implementation allows the caller to grant project trust when loading the project. Doing so requires implementation dependency on Gradle Projects module ... I hope that the ProjectReload will be soon (~ within 24 release cycle) move into project API and the impl dependency can be removed.

Note: as the preerquisite PRs will be merged, I'll clean up the commits here. Only 9cf5c1c should remain at the end.

[dbalek]

Looks fine to me.

[sdedic]

During testing, I've discovered that GradleSourcesImplTest fails quite often. I invested nearly one day into hunting the cause - and was only able to cure some symptoms.
The main issue is that the project Lookup initializes lazily; although the project impl itself uses ProxyLookup.setLookups, the delegates (actully wrapped FolderLookup ) start to initialize / recognize layer registrations and only after a while they asynchronously finalize, firing events that are propagated upwards through wrapper ProxyLookups.

This is a general problem and affetcs all (even production) code that uses pattern:

Project p = FileOwnerQuery.findOwner(someFile);
OpenProjects.open(new Project[] { p }, false);
OpenProjects.openProjects().get();
Sources srcs = ProjectUtils.getSources(p);

though the client code even opens the project in a hope it will be fully initialized afterwards, the Sources may report no source groups as the java-specific provider might not be recognized/loaded yet. This happens randomly.

In this PR, I've introduced waitForProjectLookup that hides a hacky way how to wait for the project lookup's implementations to initialize.

[mbien]

note that gradle tests are known to be unreliable, java/gradle.java is already wrapped in a retry script. (and btw they can't run on JDK 21(!))

So the problems experienced here could be new or potentially just highlight already existing issues by changing the timing. (one of the consequences of unreliable tests: you can never be sure)

[sdedic]

@mbien I am 90% sure the problem (or its root cause) is ages-old; will manifest itself primarily in tests, as the query almost immediately follows project open with a not-yet-recognized contents of the layers ... IMHO it affects the IDE only in a limited way, as in a typical "bootrstrap" the IDE displays whatever is available then refreshes on change events (which will come). But automated operations after POM/build.gradle change are in much greater danger, especially if adding a technology dependency (i.e. micronaut, spring, ...) to the project.

This issue affects equally Maven - and most probably any tests that setup maven/gradle project and then try to "read something", as e.g. java / micronaut / ejb providers do not initialize in a consistent way.

I'd like to invent "something" that would allow the projects to fire e.g. another property change event on full initialization, but it will be ... rather hard; I'll try to minimize API changes.

[mbien]

the only maven related sporadic test failure I remember is #7263. But we could check master merges and build some statistics if needed since they have retry script warnings and also logs of my manual restarts.

also note that contrary to the gradle tests, those are not wrapped in retry scripts. The retry scripts for gradle tests fire often.

[sdedic]

Stats would be good to observe the change in gradle after this merges. The test hack may stabilize some things, that's why I put it into the abstract test core many of the tests derive from.

[sdedic]

If no objections are raised, will merge this PR tomorrow early morning.