Create/Update Tests constantly introduces incorrect JUnit dependency version

### Apache NetBeans version

Apache NetBeans latest daily build

### What happened

Create/Update tests should, in maven projects at the least, detect if a JUnit (or whatever - TestNG likely has the same problem) dependency *already exists in the project*, and either

* Not modify the `pom.xml` at all, or
* At the very least, not insert a `` tag if the dependency is already satisfied

Using locally built nightly build + Maven 3.8.6 in a a large tree of maven projects with carefully managed dependencies, all of which are *using the java module system*. The Maven Enforcer Plugin is used to enforce dependency convergence - there shall be no more than one exact version of any dependency on the classpath.

Every time I use Create/Update tests, a `5.6.0` entry is added to the *already existing* `` entries for `junit-jupiter-api`, `junit-jupiter-params`, and `junit-jupiter-engine`, inherited from the `` section of the superpom, with a version of `5.8.2`. So, dependencies no longer converge and the next build fails.

The IDE could easily either examine the artifacts in the dependency graph to determine that the dependency is not satisfied, or examine the project classpath and test for one type known to be in each library, and simply skip doing any messing with dependencies - it doesn't need to.

I have not seen this before working in non-modular project, so I am not sure if the presence of a module-info somehow makes the fact that the dependencies are there opaque to the infrastructure that decides to fiddle with dependencies.

That, and the fact that the superpoms live in a different git repository and cannot be referenced by relative path are the two things that are somewhat unusual about the projects I have encountered this on.

So I am not sure if something changed in the plugin and broke former, good handling of adding junit dependencies; or if it has always been broken if you are using the module system, and I simply never triggered the problem before.

### How to reproduce

Create a superpom maven project. To replicate the exact setup in which I am encountering this, do **not** have it accessible via ``. Give it, at minimum, properties and a dependency management section like this:

```xml
5.8.2


org.junit.jupiter
junit-jupiter
${junit5.version}


org.junit.jupiter
junit-jupiter-api
${junit5.version}


org.junit.jupiter
junit-jupiter-engine
${junit5.version}


org.junit.jupiter
junit-jupiter-migrationsupport
${junit5.version}


org.junit.jupiter
junit-jupiter-params
${junit5.version}

org.apache.maven.plugins
maven-enforcer-plugin
3.0.0


enforce




3.8.6

Build requires Maven version 3.8.6.





enforce






```

In the project you will create tests in, create some class to test, and give the project a `module-info.java` in the default package. Set up the parent in its pom to be your superpom project - e.g.

```xml

test.mytestorg
my-test-superpom
0.0.1


```

and give it dependencies on junit 5 *without specifying the version* (since that is inherited and should only be specified in one place):

```xml

org.junit.jupiter
junit-jupiter-api
test


org.junit.jupiter
junit-jupiter-params
test


org.junit.jupiter
junit-jupiter-engine
test

```

Each time you add a test, a (wrong) ` entry will be added to each dependency, which you have to go delete.

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

No / Don't know

### 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

Every time I use Tools > Create/Update Tests on the popup menu for a Java source to create a new test in a project with existing tests and existing JUnit dependencies.

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

No

### Code of Conduct

Yes

Start with Tools > Create/Update Tests for a Java source in the described Maven project, using the module-info.java, superpom, dependencyManagement, and existing JUnit dependencies from the reproduction. Trace where the action inserts dependency versions into pom.xml and compare behavior before and after the action. Done means existing managed JUnit dependencies are not given incorrect version entries and the reproduced dependency-convergence failure no longer occurs.

Written by the indexing model from the issue text.