Automatic-Module-Name not detected from modular project after non-module project providing it is open

### Apache NetBeans version

Apache NetBeans latest daily build

### What happened

Working on a modular java project which _uses_ a non-modular project which _does_ have an Automatic-Module-Name entry in its manifest, referenced by the `module-info.java` in the modular project, everything works fine, _until I open the non-modular library as a project in NetBeans as well_.

After that, the module name is no longer recognized, an all sources that use classes from the library are marked with errors.

Closing the library project and restarting does not solve the problem. Deleting `index/` and the maven cache directories does not allow the IDE to forget the location of the library and begin working correctly again. I have no idea where this is getting cached (maybe it gets rediscovered via recent-projects in NbPreferences?), but short of deleting userdir and cache dirs, I have yet to find a way to recover.

(detailed steps with projects to check out to reproduce below).

### What appears to be going on

* The IDE detects Automatic-Module-Name correctly in the case that the JAR file is used in the local Maven repo
* Once the project is open, since it is the same version referenced in the modular project's POM file, classes from the project are used directly - and there is no manifest to read

### How you'd fix it:

* If one doesn't exist, there likely needs to be an SPI for Java project implementations to provide a `Manifest` for the project - or at least a module-name - synthesizing it on the fly if need-be
* Maven support needs to provide an implementation that does something along the lines of
* Look for the `maven-jar-plugin` in the project's pom or its parents' poms
* If it exists, look for one of
* A manifest file being pointed in its configuration
* Look for a configuration -> archive -> manifestEntries configuration element, and if present, collect (at least) the entry for `Automatic-Module-Name`

### How to reproduce

Exact steps to clone two projects and reproduce the problem:

1. Clone this project https://github.com/telenav/cactus and build it once - this project uses the java module system
2. In the checkout dir, run `git checkout 1e61b40e34e5a09aa6f30d7c13c0df25d1ddecc5`
3. Build it once to make sure there are classes to scan - `mvn -Dmaven.test.skip=true install`
4. Open some of the child projects in NetBeans - I'd recommend cactus-maven-model
5. Browse around - there should be no error markers or problems
6. Clone this project https://github.com/timboudreau/util which contains several libraries that are used from the previous one. This project does not use the java module system, but does provide an Automatic-Module-Name via its manifest
7. In the checkout dir, run `git checkout 788f7fbed4c683874d234e61a494f16d7deb7bb5`
8. Build it once to make sure there are classes to scan - `mvn -Dmaven.test.skip=true install`
9. Open the `function` project from the `util` checkout
10. Error markers appear all over source files in the cactus project (you may need to do some editing or rebuild to make sure a reparse happens)

### Did this work correctly in an earlier version?

No

### Operating System

Mac OS X 21.4.0, Apple Silicon 10 Core MacBook Pro

### JDK

Amazon Corretto 17

### Apache NetBeans packaging

Own source build

### Anything else

_No response_

### Are you willing to submit a pull request?

Yes

### Code of Conduct

Yes

Reproduce the failure with the cactus and util projects using the listed commits, then compare the modular project's module-info.java and the opened library project's POM and manifest configuration. Start by tracing how Maven project dependencies switch from the local JAR to project classes and how Automatic-Module-Name is obtained. Done means the module name remains recognized and source files no longer show errors after the library project is opened.

Written by the indexing model from the issue text.